View mode: basic / threaded / horizontal-split · Log in · Help
October 10, 2006
Lisp vs. C++ (not off-topic)
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.
October 10, 2006
Re: Lisp vs. C++ (not off-topic)
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.
October 10, 2006
Re: Lisp vs. C++ (not off-topic)
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/
October 10, 2006
Re: Lisp vs. C++ (not off-topic)
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.
October 11, 2006
Re: Lisp vs. C++ (not off-topic)
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.
October 11, 2006
Re: Lisp vs. C++ (not off-topic)
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.
October 11, 2006
Re: Lisp vs. C++ (not off-topic)
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
October 11, 2006
Re: Lisp vs. C++ (not off-topic)
> 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
October 11, 2006
Re: Lisp vs. C++ (not off-topic)
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
October 11, 2006
Re: Lisp vs. C++ (not off-topic)
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.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home