On Dec 16, 2011, at 2:54 PM, Andrei Alexandrescu wrote:
> On 12/16/11 4:21 PM, Sean Kelly wrote:
>> On Dec 16, 2011, at 12:26 PM, Andrei Alexandrescu wrote:
>>
>>> On 12/16/11 1:07 PM, Sean Kelly wrote:
>>>> This is fine, but the whole point of static ctors in D is to
>>>> eliminate all the stupid workarounds required to use statics in
>>>> C++. I'd much rather we find a way to make the use of static
>>>> ctors more efficient than give up on the feature.
>>>
>>> I agree, but then I think we have a design that's already there.
>>> This discusses working some kinks out of the implementation. Also,
>>> the context of the runtime/standard library is an appropriate place
>>> to take less usual measures for the benefit of many.
>>
>> But at the same time, the standard library should be an example of
>> how to do things "the right way."
>
> More often, APIs and examples given in the docs are examples of how to do
> things the right way; the standard library's implementation has a bit of a
> different charter than most application code, and this is triply true for
> systems languages. This is emphatically true for e.g. C, C++, and Perl. I
> also remember I was surprised when I peeked inside a functional language's
> library implementation. ("That's not how they teach them to write sort!")
Perhaps it's just that I come from a systems programming background and have
books like "Large Scale C++ Software Design" sitting on the shelf next to me.
I think the important distinction to be made is between sample code and real
world code. Or perhaps between code where performance is and is not an issue.
You've historically derided the quicksort example for functional programs as
useless because, while it's a very clean example of the algorithm, it's
ridiculously inefficient. So anyone who really cares about the efficiency of
their code is going to end up writing stuff that looks nothing like what you'd
find in a textbook. In short, they're going to write code that looks like
standard library code to whatever extent the skill of their programmers can
achieve. I really don't want the line between whether or not to use really
useful language features like static ctors to be whether I'm writing sample
code or professional code.
That said, I will grant that library code in general can't make any assumptions
about how the code will be used, so this is the one case where premature
optimization really is prudent. Even performance-minded application code
typically can't make the same claim because there is generally some idea of how
that code will be run, and thus tuning can be done based on profiler data. So
I suppose I'll somewhat concede your point.
