RFC on range design for D2

[Andrei Alexandrescu]

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