default random object?

[Andrei Alexandrescu]

grauzone wrote:
> Andrei Alexandrescu wrote:
>> grauzone wrote:
>>> dsimcha wrote:
>>>> == Quote from Walter Bright (newshound1 at digitalmars.com)'s article
>>>>> Andrei Alexandrescu wrote:
>>>>>> 2. The global random generator will be allocated per thread. Are you
>>>>>> cool with this too?
>>>>> That could have speed problems with a tight loop accessing thread 
>>>>> local
>>>>> storage.
>>>>
>>>> I don't think this matters, since for apps that really need it, a 
>>>> RNG can be
>>>> explicitly passed in.  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.  Also, checking thread_needLock() is dirt cheap, in my 
>>>> experience
>>>> faster than accessing TLS.  You could also have a global, non-thread 
>>>> local RNG
>>>> that is used if a check to thread_needLock() returns false.
>>>
>>> I don't understand this. If implemented right (D2.0 or gcc thread 
>>> variables), TLS can be as fast as a normal global variable. You only 
>>> need an additional check (a simple if()) to lazily initialize the RNG.
>>>
>>> Regarding "just work": it seems D's philosophy, to prefer to do the 
>>> simple and "right" thing instead of raw efficiency, seems to be 
>>> abandoned. Like std.algorithm uses weird string mixins, and the 
>>> predicate is a template argument instead of a normal one (that's IMHO).
>>
>> Well I can only welcome the return of persistent flamebaiting to this 
>> group. D's philosophy is to prefer to do the right thing, even when that 
> 
> Why is it "flamebaiting" when I say my opinion? Others are doing it too.
> 
> Here, I even used "IMHO" to mark that this is my opinion, and not 
> necessarily some kind of objective truth.
> 
> And if you think I'm trolling, then you obviously shouldn't take the 
> bait. Else you'd add quite some fuel for an actual flamewar. I really 
> don't understand this.

Yah, you're right. I shouldn't have answered, and my answer ended up 
going firmly further out of line. I am sorry about that. If you care for 
my reasons, please read on.

Now I do understand in the end you're doing nothing but stating an 
opinion, which is of course what we do most of the time. All I'm saying 
is that it's more beneficial to discuss an opinion of the form:

"I prefer froobenglobs to std.brooblenglabs. I think std.brooblenglabs 
are unnecessarily complicated with too few redeeming qualities. In 
contrast, froobenglobs have the simplicity given by using the universal 
trilegate feature, and their inherent loss of quantic traction is 
negligible. So I suggest froobenglobs to be considered as a supplement 
or replacement for a future std.brooblenglabs."

This is an opinion that can be discussed because it brings supporting 
arguments that can in turn be debated. Many good things transpire that 
way. Should we reach the conclusion that our views on the matter differ 
in some irreducible manner, we'll still be gained from the discussion. 
Contrast this with not an opinion, but an umbrella statement that 
implicitly assumes a number of opinions are true facts:

"Everything about C++, language and libraries, reeks of bad design" 
(this is how I read your ironic statement to the contrary).

or

"It looks like D's philosophy to do the simple and right thing instead 
of raw efficiency has been abandoned."

This (and the subsequent example) after I've spent time on several 
occasions on explaining you how and why exactly pass-by-delegate is not 
defensible versus pass-by-alias, which includes pass-by-delegate in its 
jeans pocket. The "IMHO" license you use does little to help such 
statements. I agree the odd rules of pass-by-string may seem unsavory to 
some, but please agree with me that there is little in the way of a 
salient answer that could be given to the umbrella statement above.

>> This means that, had std.algorithm taken the "normal" route, it would 
>> have been plenty useless for any serious needs. Not taking the 
>> "normal" route means that its abstractions rival hand-tuned code so I 
>> can use them without worrying they will come unglued when shown a real 
>> challenge.
> 
> That's what I said. You preferred this design because it's faster. One 
> can agree or disagree if this approach introduces "syntax artifacts" or 
> if it violates KISS or whatever. Everything has its pros and cons. I 
> just said I disagree.

I preferred that design not only because it's faster, but also because 
it _includes_ *all* /benefits/ of the "slower" rule of pass-by-delegate, 
i.e. it can be slower and more flexible if that's what's needed. The 
only "cost" is a minor change in usage syntax. Essentially I think D has 
hit mother lode with the local instantiation feature because it has all 
the benefits and next to no problem. I sincerely believe it will be 
instrumental to the success of D.

Given its advantages, it would be an extraordinary uphill battle to 
argue that pass-by-alias with local instantiation is a lesser design. 
What pushed my button is not that you undertook said battle, but that 
you made statements that imply you've already won it.

> 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