• bearophile <bearophileHUGS lycos.com> Sep 09 2008
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Sep 09 2008

bearophile <bearophileHUGS lycos.com> writes:

Andrei Alexandrescu:

For my money, other collection/algorithms designs don't hold a candle to STL's.<


I know that the STL is a highly refined piece of technology; after reading lot
of things written by Alexander Stepanov I was impressed.

Still, other languages don't care of the STL because they really want to be
simpler than C++ (I think you probably need a significant part of the
complexity of C++ language to implement a good STL), so the other languages
(and their std libs) may look worse to you, but for a lot of people those
languages and std libs aren't worse, they trade some power (that you can find
in STL) with a simpler language that more programmers may want to use. The
practical result is that today there may be two programmers using the Java std
lib for each C++ STL user.
From what I have seen lately D is leaving Java (and C#) and it's trying to
become closer to C++.


I know it's a matter of balance. I am not sure what gave you the idea that I
didn't.<


Probably your balance seems toward more complexity than I like to have in a
language. I presume Walter will follow your advice, but a too much complex
language (even if more powerful and more efficient than the current D) may not
be what most people look for. We'll see if I'm right.
I'm not good enough yet to design a language, so I have to leave you the work
:-)


I think many would agree that foreach minus the disadvantages would be better.<


Only if the increase in complexity for this specific thing is perceived by most
D programmers as less important than the improvement in performance and
flexibility, of course :-)


How do I know that? Because I measured. Why did I measure? Because I care. Why
do I care? Because the typical runtime of my programs measure in hours of sheer
computation, and because things like reduce and others in std.algorithm are in
the core loops. And I am not alone.<


I can see there's a large difference in purposes here, while I too care and I
too have written few thousands of lines of code to benchmark most things I have
written, the point of my functional stuff lib is mostly to replace code that's
not in core loops, it's designed to improve coding for the 80-90% of the code
where performance isn't so important.


Costly abstractions are a dime a dozen. It's efficient abstractions that are
harder to come across.<


I have understood this only after reading long texts by Alexander Stepanov
regarding the STL :-) That's where I have gained respect for the STL and the
C++ language, and their designers.

But elsewhere I have also realized that in a very large percentage of lines of
code in a program (80%?) you don't need max performance, and in such parts of
the code there are other things that deserve to be maximized: succinctness of
code, flexibility, usage simplicity, adaptability to a large number of
situations, anti-bug-prone coding, etc. About the same qualities a built-in
data structure like the Associative arrays is useful for. Paying the price that
comes from code that strives for max performance in the whole program leads to
lot of brainpower required to write the code, very complex bugs, etc.


If you believe I am wasting time with cutesies in std.algorithm, please let me
know of the places and of the suggested improvements.<


There are few things I don't like there, but nothing major :-)
Time ago I have posted something in the main D newsgroup, I think few things
are changed in the meantime (I think Walter has improved max/min):

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=67113


I agree.<


Oh good, then you may agree with me that the langage too may enjoy to have some
ability to "scale down" :-)


To quote a classic, Lisp has had them all for 50 years.<


But Python syntax is few lightyears ahead compared to CLisp ;-)


I plan to implement things like lazyMap and lazyReduce,<


I presume the large body of (refined) code I have already written on this in my
libs is useless to you, because it's based on opApply... But maybe you can find
use in few names, some argument lists, etc (In the next days I have some of
that code to show to Walter, but it becomes even more useless for Walter now).

Thank you for the patience and your kind answers,
bye,
bearophile

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

bearophile wrote:
 Andrei Alexandrescu:
 
 For my money, other collection/algorithms designs don't hold a
 candle to STL's.<


 I know that the STL is a highly refined piece of technology; after
 reading lot of things written by Alexander Stepanov I was impressed.
 
 Still, other languages don't care of the STL because they really want
 to be simpler than C++ (I think you probably need a significant part
 of the complexity of C++ language to implement a good STL), so the
 other languages (and their std libs) may look worse to you, but for a
 lot of people those languages and std libs aren't worse, they trade
 some power (that you can find in STL) with a simpler language that
 more programmers may want to use. The practical result is that today
 there may be two programmers using the Java std lib for each C++ STL
 user. From what I have seen lately D is leaving Java (and C#) and
 it's trying to become closer to C++.


Thanks for your continued comments.

I agree with most of what you say, so probably most differences are in 
the nuances. First nuance is that you seem to expose a false dichotomy: 
"simple" versus "allows power"/"allows STL".

For all I know, much of Walter's claim to fame with D is that he proved 
that power/efficiency and ease of use are not an either-or choice as 
most people thought.

Also for all I know, D already is more powerful than C++. There are a 
few remaining stragglers such as return by reference. Given that D is 
already more powerful than C++ and also much simpler, we could take one 
of two routes:

1. Implement STL in D, which, as std.algorithm shows, is compellingly 
simpler and better than its C++ counterpart.

2. Implement an inferior containers/algorithms design from a less 
powerful language.

I'd say you'd have to bring a very strong case for (2) to make it stick.

There's one more nuance to bring up here. D is meant to be a 
systems-level programming language, and as such one clear goal of it is 
to obviate a need for C++. In the inner circles of C++ there's often 
talk about how a replacement for C++ looks like, and to quote a classic 
who reflects the general opinion: "Whatever replaces C++ should be at 
least as good as C++ at whatever C++ is good at, and better than C++ at 
whatever C++ is bad at."

 I know it's a matter of balance. I am not sure what gave you the
 idea that I didn't.<


 Probably your balance seems toward more complexity than I like to
 have in a language. I presume Walter will follow your advice, but a
 too much complex language (even if more powerful and more efficient
 than the current D) may not be what most people look for. We'll see
 if I'm right. I'm not good enough yet to design a language, so I have
 to leave you the work :-)


As the thread on T.fail shows, I'm fighting tooth and nail against 
adding complexity to the language whenever it can be helped.

 I think many would agree that foreach minus the disadvantages would
 be better.<


 Only if the increase in complexity for this specific thing is
 perceived by most D programmers as less important than the
 improvement in performance and flexibility, of course :-)
 
 
 How do I know that? Because I measured. Why did I measure? Because
 I care. Why do I care? Because the typical runtime of my programs
 measure in hours of sheer computation, and because things like
 reduce and others in std.algorithm are in the core loops. And I am
 not alone.<


 I can see there's a large difference in purposes here, while I too
 care and I too have written few thousands of lines of code to
 benchmark most things I have written, the point of my functional
 stuff lib is mostly to replace code that's not in core loops, it's
 designed to improve coding for the 80-90% of the code where
 performance isn't so important.


And what would you rather have in the standard library? And what 
advantages are you showing in exchange for the steep penalty in 
efficiency? (I looked over your library a while ago and it seems to use 
delegates everywhere.)

 Costly abstractions are a dime a dozen. It's efficient abstractions
 that are harder to come across.<


 I have understood this only after reading long texts by Alexander
 Stepanov regarding the STL :-) That's where I have gained respect for
 the STL and the C++ language, and their designers.
 
 But elsewhere I have also realized that in a very large percentage of
 lines of code in a program (80%?) you don't need max performance, and
 in such parts of the code there are other things that deserve to be
 maximized: succinctness of code, flexibility, usage simplicity,
 adaptability to a large number of situations, anti-bug-prone coding,
 etc. About the same qualities a built-in data structure like the
 Associative arrays is useful for. Paying the price that comes from
 code that strives for max performance in the whole program leads to
 lot of brainpower required to write the code, very complex bugs, etc.


Again you offer a false dichotomy. Do I want a beautiful wife or a smart 
one? D code can enjoy the properties you mention without needing to pay 
an arm and a leg for them.

 If you believe I am wasting time with cutesies in std.algorithm,
 please let me know of the places and of the suggested
 improvements.<


 There are few things I don't like there, but nothing major :-) Time
 ago I have posted something in the main D newsgroup, I think few
 things are changed in the meantime (I think Walter has improved
 max/min):
 
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=67113


Thanks. I'll heed some of the comments, particularly those regarding 
laziness. In fact I'm thinking that map should be lazy by default.

 I agree.<


 Oh good, then you may agree with me that the langage too may enjoy to
 have some ability to "scale down" :-)
 
 
 To quote a classic, Lisp has had them all for 50 years.<


 But Python syntax is few lightyears ahead compared to CLisp ;-)
 
 
 I plan to implement things like lazyMap and lazyReduce,<


 I presume the large body of (refined) code I have already written on
 this in my libs is useless to you, because it's based on opApply...
 But maybe you can find use in few names, some argument lists, etc (In
 the next days I have some of that code to show to Walter, but it
 becomes even more useless for Walter now).


If there are no licensing issues (which Walter is weary of) I'd be 
grateful to benefit of your code or designs. Do you have a link handy?


Andrei