Andrei Alexandrescu Wrote: > 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
Point #3 is on the mark. A URL to quality documentstion is worth 100 posts declaring the superiority of dlibs.
