On Friday, 12 April 2013 at 10:14:35 UTC, Regan Heath wrote:
All true. However, complexity can and should be packaged in
such a way as to localise, and this localised complex code
should be tested to death and maintained by someone who
understands it. It should be bracketed by sufficient comments
and warnings about how/why it does what it does. The resulting
packaged complexity, with it's associated cost can be re-used
many times over for all the benefit it gives.
Stack allocating the environment variables need not be a
localised improvement but could be a standard library function
which can be reused, for example.
Performant abstractions. Like the much-awaited allocator design?
Either way, they can only diminuate, not remove the costs.
Would you still say that the above costs are worth the
nearly-intangible gain?
"nearly-intangible" is wrong. Library code is code which is
used by (hopefully) millions of people, writing millions of
applications, running for millions of hours, on millions of
systems, creating thousands of processes, etc.. In short, a
little effort now pays massive dividends over it's lifetime.
So, yes, IMO the costs shown above are worth the resulting
gains.
D is constantly being compared to other languages on the basis
of performance, so it's clearly an important aspect of D's
success.
Library code needs to work first time and work well or people
will roll their own wasting time, energy and in many cases
getting some aspect of it just plain wrong.
But once again, you speak in vague terms.
Consider the following hypothetical decisions and outcomes:
1. std.process is left at is. One user is angry / turned away
because it performs 0.1% slower than it can be.
2. std.process is rewritten to minimize allocations. Code
complexity goes up, new improvements are challenging to add; bugs
pop up and go unfixed for a while because fewer programmers are
qualified or willing to commit the effort of making correct
fixes. More people are angry / turned away from D because its
standard library is buggy.
Of course, the above is an exaggerated illustration. But would
optimizing all code left and right really make more D users
happier?
There's also the question of priorities. Would you rather than
effort is spent on optimizing std.process (and dealing with all
the fallout from any such optimizations), or working on something
that is acutely missing and hurting D?
D is a systems programming language, there is hope that it will
penetrate a wide range of systems and environments - sure in
many cases a little bit of memory use or performance loss is
unimportant, but for many it will be the decisive factor which
makes D unusable there.
This is surely an exaggeration.
D does not attempt to please everyone out there who is choosing a
programming language for their next project. There is no such
language, nor can one exist. One has to accept that D has a
number of goals, none of which are absolute, but merely point
towards a certain, but not overly specific, point in the
multidimensional matrix of trade-offs. D never was about
achieving maximum performance in all possible cases.
