Neal Alexander wrote:
> Robert Fraser wrote:
>> Walter Bright wrote:
>>
>>> An oldie, but some very thought provoking observations on what makes a language productive:
>>>
>>> http://faculty.cs.byu.edu/~irenelg/courses/330/CTM/Resources/C++-vs-Lisp.txt 
>>
>> Concise does not always mean readable, and reducing lines of code should *never* be a design goal. For example, if I removed many temporary variables and used long expressions (as is the style in many functional languages), I could probably chop off 1/5-1/4 of the LOC of my program, but debugging/fixing it would get much harder. Additionally, redundancy (as stated in the ";" topic) is not necessarily a bad thing as it helps reinforce meaning to readers.
> 
> Dunno heh, some functional languages tend to have a much easier time with spreading dense logic into smaller segments. Its not about just packing in as much logic as you can per line. You show the high level interaction between functions and abstract away the gory details of the implementation.
> 
> f x =
>     write x =<< mutate =<< read x
> 
>     where
>         mutatate list = do
>                         ...

One of the reasons we have inner functions in D now.

Neal Alexander wrote:
> Walter Bright wrote:
> 
>> An oldie, but some very thought provoking observations on what makes a language productive:
>>
>> http://faculty.cs.byu.edu/~irenelg/courses/330/CTM/Resources/C++-vs-Lisp.txt 
>>
> 
> It'll be interesting to see where D goes with the functional stuff.
> 
> Some nice things i think you should steal from Haskell:
> 
> 
> - One of the interesting things about programming/reading haskell code is how a function's definition is structured. Each "where" clause is like zooming in on a microscope or whatever. Most of the time you can just look at the top levels and understand what the function does without even looking at the inner definitions. This gives a lot of locality to the code.
> 
> - Thinking in terms of map/fold/zip/recursion is really a lot nicer than manually looping. Once you write code that can deal with 1 instance, it pretty much automatically can be applied to multiple sequences without any real changes.
> 
> - Function composition: (process . reverse . sort) list
> vs
> process(reverse(sort(list)))
> 
> - Partially applied functions
> 
> - Good type inference
> 
> - The "Maybe" monad provides a clear transport for possible failure. One of the nice things about it is how you can force different error handling behaviors. Short circuit, Pattern Match exception etc.
> 
> - Restricting mutability to the absolute bare minimum helps reason about behavior.
> 
> 
> D already has the groundwork for the large majority of these features, but unfortunately has to rely on template hacks. In my opinion, one of the worst problems with D is going through the template system for alot of the advanced features (currying, tuples etc). Its not as bad as Boost but still.

At least D /has/ templates. And I suspect that once some template idiom becomes standard usage, Walter or Andrei may just decide to incorporate it into the language proper.

Thus, we have a seeding bed indoors, and the plants that really start to grow, get planted in the garden so they can grow into strong trees.

(Heh, organic growth. D should get an Environment Sticker!)