lazy thoughts

[Andrei Alexandrescu]

bearophile wrote:
> Andrei Alexandrescu:
>> I'll wait for bearophile to tell if he feels he hasn't gotten the
>> credit he believes he deserves before I answer this particular
>> point.
> 
> I'm having a bad week for matters unrelated to D. You are doing lot
> of work for D, so don't worry for me. I was just a bit sad seeing you
> inventing some things I use often and I have shown here few times.
> 
> Consider the idea of having both lazy/eager versions of your
> functors.
> 
> Consider the idea of having a functionality like the xchain functor
> and Chainable class mixin of my libs (that is lazy chaining of
> arbitrary iterables, eager and lazy) using ~.
> 
> I have also created various other things that you may re-invent in
> the following days and weeks, like the Xcast, a way to cast lazily
> the items of an iterable, etc.
> 
> One small but important thing I think has to be fixed in D2 is
> related to associative arrays in D: iteration has to happen first of
> all on keys. This gives big practical advantages. In my libs all
> functions when confronted with AAs use their keys first.
> 
> In my dlibs I have implemented several other things that I hope to
> see in D2, like the record/Record that is a much better Tuple, a
> better equality testing among arrays, testing and comparison among
> associative arrays, etc. I have explained such things few times, but
> I am willing to explain them again, if there's someone willing to
> listen.

I understand. It would be great to solve this to everybody's 
satisfaction, and I think it's entirely possible.

First off, allow me a rather general comment stemming from experience. 
The problem with little ideas like that is exactly that they are little 
- they are often hard to give credit for, and they may occur 
independently to many people. Over time I've shared many such little 
ideas with the C++ community in various venues, and I've often found 
them used without credit. The true solution is simply to let that go and 
hunt for bigger ideas. Bigger ideas have more impact, have larger uses, 
and are less likely to occur to others independently.

Second, you'd hopefully give me that I'd heard of the benefits of lazy 
evaluation before having joined this group. The reason today's 
std.algorithm forgoes lazy evaluation is that iterating lazy structures 
is either very cumbersome (proxies) or very inefficient (opApply). 
Cumbersome abstractions will hardly become popular, and I hold costly 
abstractions in utter contempt. They are a dime a dozen and putting them 
straight in the core language and/or standard library would surely 
hamstring everything using them in actuality or in spirit. (Alan Perlis: 
"Lisp programmers know the value of everything and the cost of nothing." 
Well that has changed in modern Lisp because the prevalence of macros 
has grown appropriately, but it's still funny.) That's why the real 
problems to solve were things like figuring out an efficient way to 
define higher-order functions (via alias usage versus slow delegate 
usage), a solid iteration abstraction, and rendering opApply obsolete. 
That was the hard problem, not implementing higher-order functions or 
lazy algorithms. Once the solution was in place, the door is open for 
all sorts of cool stuff, and here's where you can add beneficial influence.

This brings me to a third issue. If you want to make dlibs popular, 
talking about it on the newsgroup is a very inefficient way. Many 
discussions come and go on the newsgroup. I seem to remember that for 
the longest time you only provided your library as a downloadable zip 
file (with html documentation *inside* the zip). I want you to sit for a 
minute and ponder about the obtuseness of such a setup. It's almost like 
you wanted to just make a token acknowledgment of your own work, while 
keeping it in fact thoroughly obscure. Then, after finally having put 
the library online (at my behest as far as I remember), its online 
documentation could stand significant improvement and examples. You 
could do so with a fraction of the effort you spend on this newsgroup 
e.g. explaining your putr function (which, as expected, came and went 
and is now largely forgotten). If I were you I'd probably add some nice 
examples to the documentation and put a link to it in my .sig. Then, 
whenever you want to make a point, you can simply refer people to links 
to your documentation and examples, instead of sitting down and writing 
rationale and examples every time the discussion comes close.


Andrei