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

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

I wonder how D would perform?  It looks like D could be as almost as streamlined as lisp with its built-in containers.

It seems to me though that size of a program isn't everything.  As you said before, repetition helps reduce errors.  I think D provides better mechanisms for abstraction then lisp.  I think that D allows one to work on much larger problems more effectively then lisp.  I think there in lies the trade off.

If/when D gains functional programming it will have the best of both worlds.

-Joel

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.

Robert Fraser wrote:
> 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.

There's good redundancy, and there's bad redundancy:

http://reddit.com/info/6ip9w/comments/

http://dobbscodetalk.com/index.php?option=com_myblog&show=Redundancy-in-Programming-Languages.html&Itemid=29

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.

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
                        ...

"Neal Alexander" <WQEQWEUQY@HOTMAIL.COM> wrote in message news:g0nha0$1s9l$1@digitalmars.com...
> - Function composition: (process . reverse . sort) list
> vs
> process(reverse(sort(list)))
>

Did you mean:

(sort . reverse . process) list
vs
process(reverse(sort(list)))

Or does Haskell put them in order of (last . first)?  FWIW, I really like the style I've seen in some languages that's basically:

list.sort().reverse().process()
vs
process(reverse(sort(list)))

Which, I'm assuming is what you're talking about, but not certain.

Nick Sabalausky wrote:
> "Neal Alexander" <WQEQWEUQY@HOTMAIL.COM> wrote in message news:g0nha0$1s9l$1@digitalmars.com...
>> - Function composition: (process . reverse . sort) list
>> vs
>> process(reverse(sort(list)))
>>
> 
> Did you mean:
> 
> (sort . reverse . process) list
> vs
> process(reverse(sort(list)))
> 
> Or does Haskell put them in order of (last . first)?  FWIW, I really like the style I've seen in some languages that's basically:
> 
> list.sort().reverse().process()
> vs
> process(reverse(sort(list)))
> 
> Which, I'm assuming is what you're talking about, but not certain. 
> 
> 
Nah its read right to left.

"(f . g) x" is the same as "f (g x)"

http://en.wikipedia.org/wiki/Function_composition_(computer_science)

Anyway, its similar to list.sort().reverse().process() in that you can create pipelines like that. But its different in that it joins two functions to create a new one - without having to apply any arguments to it right away.

list.sort().reverse().process() can be looked at as a Monad too i guess.

"process =<< reverse =<< sort =<< return list"

(right to left again - with sort, reverse, and process allowing side effects)

Neal Alexander Wrote:

> Nick Sabalausky wrote:
> > "Neal Alexander" <WQEQWEUQY@HOTMAIL.COM> wrote in message news:g0nha0$1s9l$1@digitalmars.com...
> >> - Function composition: (process . reverse . sort) list
> >> vs
> >> process(reverse(sort(list)))
> >>
> > 
> > Did you mean:
> > 
> > (sort . reverse . process) list
> > vs
> > process(reverse(sort(list)))
> > 
> > Or does Haskell put them in order of (last . first)?  FWIW, I really like the style I've seen in some languages that's basically:
> > 
> > list.sort().reverse().process()
> > vs
> > process(reverse(sort(list)))
> > 
> > Which, I'm assuming is what you're talking about, but not certain.
> > 
> > 
> Nah its read right to left.
> 
> "(f . g) x" is the same as "f (g x)"
> 
> http://en.wikipedia.org/wiki/Function_composition_(computer_science)
> 
> Anyway, its similar to list.sort().reverse().process() in that you can create pipelines like that. But its different in that it joins two functions to create a new one - without having to apply any arguments to it right away.
> 
> list.sort().reverse().process() can be looked at as a Monad too i guess.
> 
> "process =<< reverse =<< sort =<< return list"
> 
> (right to left again - with sort, reverse, and process allowing side effects)

This is so beautiful in new pipe in std.functional. Because you can group intuitive left to right. And does good work as compose! I look at definition it is this:

template pipe(fun...)
{
    alias compose!(Reverse!(fun)) pipe;
}

I am not 100% sure but think there is no new function, just rename of compose. So no runtime work. Very nice. Dee Girl

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 

Interestingly, this same analysis was posted by Josh Stern in 2006 on D.announce.  You were even involved in the ensuing discussion quite a bit :-)


Sean