Vote for std.process

[Regan Heath]

On Fri, 12 Apr 2013 10:17:54 +0100, Vladimir Panteleev  
<vladimir at 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/