On Fri, 12 Apr 2013 10:17:54 +0100, Vladimir Panteleev
<vladi...@thecybershadow.net> wrote:
On Friday, 12 April 2013 at 08:57:19 UTC, Regan Heath wrote:
I don't understand why you're so "against" these comments. There is no
real "argument" here, you both want std.process to be as good as it can
be and it will clearly be better if it performs faster and allocates
less.
This is a fallacy.
Nope, you're attacking a Strawman here. At most my statement is
incomplete because it doesn't address the costs (which I left out for
brevity).
Performance is not free.
I never claimed it was (thus the Strawman). I simply claimed std.process
would be "better" if it performed faster and allocated less - which is
true.
Somebody must do the work.
D contributors do not have an infinity of time and motivation.
I know this as well as anyone, my own free time is in short supply.
Optimizing code often implies making it more complicated.
Straight-forward code is self-documenting.
More complicated code is harder to read and review.
More complicated code more easily hides bugs - including security bugs,
such as buffer overflows.
Maintaining optimized code requires understanding not only the
high-level logic, but also the low-level optimization details.
The benefits of optimizing std.process are likely to be so small, as to
be difficult to measure.
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.
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 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.
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.
Again, I'm not suggesting (nor was Manu I think) that this in any way
blocks the inclusion of std.process. But I do share his desire for
performance to sometimes be a little higher up the priority list.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
