default random object?

[grauzone]

dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at 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.