== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > > Also, dsimcha said: > > > This is purely a convenience feature for when you want > > > random number generation to "just work" even if it's not the most > > > efficient thing > > > in the world. > > > > I agree to him. If you need efficiency, you can write your own code or > > use a highly specialized library fit for the job. Most users probably > > wouldn't rely on the standard library if they're optimizing their code. > Well, you see, here's where we can "agree to disagree" (as much as I > dislike the PCness of the phrase). IMHO, if most users in search for > efficiency need to roll their own counterparts of the abstractions > provided by Phobos, I've majorly wasted my time. Costly abstractions are > a dime a dozen. I have nothing but contempt for them. Every dog language > has them in spades. The real challenge is not to write sort in three > lines. It's to write it in three lines and have it beat the 2000 lines > sort. (Alas, we're not there yet.) > > As long as the user _can_ write his own code, the standard library > > should prefer to be simple and easy to use. It also prevents bitrot, > > bloat, and incomprehensible library code. > This approach seems to be pushing bitrot, bloat, and incomprehensibility > into the user code, while keeping the library a collection of useless > toys. Hardly an approach I'd go for. I am sorry. I just disagree. > Andrei
Just to set the record straight, I actually agree with Andrei here. Elegant but costly abstractions are simply not D's niche, and are relatively easy to come by. If you want them, use a good dynamic interpreted language instead. The quote above was taken out of context. I believe that a library should provide efficient and flexible abstractions that eliminate the need for people to roll their own and that the goal of Phobos2 in this regard is a good one. I probably wouldn't use much of what was in std.algorithm, at least in the performance critical parts of my code, if it were pass-by-delegate instead of pass-by-alias. My only point was that, when complexity in the API (or language) is unavoidable if efficiency and flexibility are to be achieved, I think it's ok to slap a few not-so-efficient convenience features on top of it as long as the core remains efficient, flexible and reasonably usable.
