dsimcha wrote:
== 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
Well, I'm not necessarily talking about "elegant but costly
abstractions". Rather, D is full of design decisions, where convenience
and simplicity was preferred to maximal achievable performance:
- relies on GC, rather bad support for fully manual MM
(also consider the new closures in D2.0)
- expensive checks in non-release mode (array bounds checking,
object invariants)
- methods are virtual by default
- foreach used to call the enclosed code as a delegate
- lazy keyword
- associative arrays, also .sort
- many runtime core and std-lib functions are designed that way
Maybe there's even more. D always has been a nice blend of performance
centered low level languages like C/C++, and higher level ones liek
dynamic or functional languages.
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.
