Vote for std.process

[Vladimir Panteleev]

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.