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
