This old blog doesn't mention D, but I think it is good and really relevant anyway:

http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html

IMO, it points to a set of issues that relate to how D (and its libraries)
have the potential to allow developers to be a lot more productive than
they are with C++.   Particularly relevant D features related to
the points mentioned there include but are not limited to  GC, mixins,
regex, and elimination of header/instantiation separation.   The point
about the productivity benefits of creating interfaces that return the
most interesting value (maybe alongside the interface that allows the
greatest efficiency when optimizing) is a good one to remember in practice.

I think the number of lines is over rated. This is a very simple example and doesn't really compare anything useful. Lisp may have fewer lines but the number of parenthesis counter balances this.

It really needs to compare something more complicated like a telephone PBX exchange. Lisp has a number of advantages including built in lists and this is a list problem.  It doesn't compare anything except the implementation of lists of data and should focus on something much more complex with larger variables like a 3d game engine.

Josh Stern wrote:
> This old blog doesn't mention D, but I think it is good and really
> relevant anyway:
> 
> http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html
> 
> IMO, it points to a set of issues that relate to how D (and its libraries)
> have the potential to allow developers to be a lot more productive than
> they are with C++.   Particularly relevant D features related to
> the points mentioned there include but are not limited to  GC, mixins,
> regex, and elimination of header/instantiation separation.   The point
> about the productivity benefits of creating interfaces that return the
> most interesting value (maybe alongside the interface that allows the
> greatest efficiency when optimizing) is a good one to remember in practice.


It is a very interesting article for anyone wanting to carefully look at language differences. Anyone care to try a D version following the original challenge?

   http://www.flownet.com/ron/papers/lisp-java/

On Tue, 10 Oct 2006 20:01:10 +0000, Makaan wrote:

> I think the number of lines is over rated.

I guess it depends on who is rating and how they do it.  The most obvious
problem with line counting is that it doesn't insure an apples-to-apples
comparison unless there is some way to hold quality relatively
constant.   Using small explicit tasks is one way to try to achieve the
latter.

>This is a very simple example and
> doesn't really compare anything useful. Lisp may have fewer lines but the number of parenthesis counter balances this.

What they actually measured in the referenced study was the amount of time the coding took to complete the task.  If problems with LISP syntax still hurt productivity of experienced developers then that would have already been factored into the comparison.

Looking at lines of code wasn't the base measure of productivity - it
was rather the blog author's attempt to try and explain the amount of time
it took. But my understanding parallels his in the sense that studies
which have looked at larger projects still found number of lines of code
required to be about the best predictor of the amount of time required for
a given type of project - i.e. you can't compare app coding to real-time
embedded coding, but you can you can compare across similar tasks, and
some say lines of similar quality across similar task is a way to look at
the effect of the programming language on productivity. That doesn't mean
it's a great predictor -  but it seems as good as anything else people
have come up with.

> It really needs to compare something more complicated like a
>telephone
> PBX exchange. Lisp has a number of advantages including built in lists and this is a list problem.  It doesn't compare anything except the implementation of lists of data and should focus on something much more complex with larger variables like a 3d game engine.

At least the author of the blog was taking library data structures like lists and hashmaps for granted, so that wasn't the issue per se, though he finds fault with the existing interfaces from a productivity point of view.

Walter Bright wrote:
> Josh Stern wrote:
>> This old blog doesn't mention D, but I think it is good and really
>> relevant anyway:
>>
>> http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html
>>
>> IMO, it points to a set of issues that relate to how D (and its libraries)
>> have the potential to allow developers to be a lot more productive than
>> they are with C++.   Particularly relevant D features related to
>> the points mentioned there include but are not limited to  GC, mixins,
>> regex, and elimination of header/instantiation separation.   The point
>> about the productivity benefits of creating interfaces that return the
>> most interesting value (maybe alongside the interface that allows the
>> greatest efficiency when optimizing) is a good one to remember in practice.
> 
> 
> It is a very interesting article for anyone wanting to carefully look at language differences. Anyone care to try a D version following the original challenge?
> 
>    http://www.flownet.com/ron/papers/lisp-java/


It was sooo easy in D! I got it done in 1 hour 15 minutes.. But, my results differ from theirs and I can't figure out why.

For example, my prog comes up with "3-/0--69-4: 3 echt", which seems correct ("echt" is in the dictionary and is coded as "0694"), but their output.txt has nothing for the phone number "3-/0--69-4" ???

L.

I give up. I can't figure out why those phone numbers are missing from their output.

I've attached what I have so far. It's pretty nice, readable, and uses quite a few of D goodies ;)

L.

On Wed, 11 Oct 2006 13:45:29 +0300, Lionello Lunesu wrote:

> I give up. I can't figure out why those phone numbers are missing from their output.
> 
> I've attached what I have so far. It's pretty nice, readable, and uses quite a few of D goodies ;)
> 
> L.
>It was sooo easy in D! I got it done in 1 hour 15 minutes.. But, my results differ from theirs and I can't figure out why.
>
>For example, my prog comes up with "3-/0--69-4: 3 echt", which seems correct ("echt" is in the dictionary and is coded as "0694"), but their output.txt has nothing for the phone number "3-/0--69-4" ???
> L.

I just looked in the dictionary and "etch" isn't there. Maybe you are
searching for "etch" and find "Sketch", "Ketchup"? If this is the case you
can just look for the word preceeded by \n. Hope this helps.
Can you repost your code I cannot see your attachment.
AndBre

> I just looked in the dictionary and "etch" isn't there. Maybe you are
> searching for "etch" and find "Sketch", "Ketchup"? If this is the case you
> can just look for the word preceeded by \n. Hope this helps.
> Can you repost your code I cannot see your attachment.
> AndBre

Sorry I mispelled the word, you are right, it is in the dictionary. AndBre

It's an interesting analysis, but I think some of the points of comparison aren't as strong has the writer implies.  For example, he begins by saying that his initial C++ attempt is shorter than average and suggests that this is because his is the only C++ attempt to use the STL.  Later he goes on to make a direct comparison of some of his code and some of Peter Norvig's code (in the Style section) and concludes that because Norvig's code is shorter and doesn't modify the sequence in place, functional programming is better.  He's forgotten his original statement regarding his code vs. the other C++ entrants however, and perhaps doesn't have enough experience with the STL to know that:

    words.reverse();
    cout << num << ":";
    for (list<string>::const_iterator i = words.begin();
         i != words.end(); ++i)
        cout << *i << " ";
    cout << "\n";

can be rewritten as:

    std::cout << num << ':';
    std::reverse_copy( words.begin(),
                       words.end(),
                       std::ostream_iterator<std::string>( std::cout,
                                                           " " ) );
    std::cout << '\n';

This rewrite addresses his concern about reversing the list in place to print it out (it doesn't modify the original sequence), and partially addresses the comment about having to print out the list manually.  It also reduces his LOC count by two and is almost as expressive as the Lisp version.  A further reading of his code shows that he doesn't use the algorithm library at all, which is IMO one of the greatest strengths of C++.

That said, I do agree with the general thrust of the article.  While tricks like the above are possible in C++, they tend to require a good degree of knowledge or experience to be aware of.  By comparison, I think Lisp naturally lends itself to the type of code in Norvig's example.  The Lisp code is also more succinct and more clear than even an algorithm-aware rewrite of the C++ version, though I believe the gap would be narrower than the original comparison suggests.

I believe that D has a definite opportunity to do better than C++ in code clarity and ease of programming, but I'm not sure the library is sufficient quiet yet.  The C++ algorithm/iterator model is extremely powerful and D's foreach and delegates aren't enough by themselves.  For example, writing the code snippet above in D would be much more like the original C++ version than my rewrite.  For D to be great, I think it will need an standard algorithm-oriented library that exploits D's unique language features.  DTL seemed a likely candidate, but development on it stalled ages ago.  But perhaps it contains ideas worth pursuing.  I'll admit it's been so long that I've forgotten a lot of the details of how it works.


Sean

Sean Kelly wrote:
> I believe that D has a definite opportunity to do better than C++ in code clarity and ease of programming, but I'm not sure the library is sufficient quiet yet.  The C++ algorithm/iterator model is extremely powerful and D's foreach and delegates aren't enough by themselves.  For example, writing the code snippet above in D would be much more like the original C++ version than my rewrite.  For D to be great, I think it will need an standard algorithm-oriented library that exploits D's unique language features.  DTL seemed a likely candidate, but development on it stalled ages ago.  But perhaps it contains ideas worth pursuing.  I'll admit it's been so long that I've forgotten a lot of the details of how it works.

D just needs a foreach_reverse statement.