Was: Re: Vote for std.process

[Regan Heath]

I've moved this to another thread to allay complaints.

> "Vladimir Panteleev" <vladimir at thecybershadow.net>
> On Friday, 12 April 2013 at 10:14:35 UTC, Regan Heath wrote:
>> All true.  However, complexity can and should be packaged insuch a way  
>> as to localise, and this localised complex codeshould be tested to  
>> death and maintained by someone whounderstands it.  It should be  
>> bracketed by sufficient commentsand warnings about how/why it does what  
>> it does.  The resultingpackaged complexity, with it's associated cost  
>> can be re-usedmany times over for all the benefit it gives.
>>
>> Stack allocating the environment variables need not be alocalised  
>> improvement but could be a standard library functionwhich can be  
>> reused, for example.
>
> Performant abstractions. Like the much-awaited allocator design?
> Either way, they can only diminuate, not remove the costs.

non localised improvements have a fixed cost and ever increasing benefit -  
is the point I was making here.  Agreed, you cannot remove the cost, and  
in fact well written reusable code often carries a slightly higher cost by  
it's very nature.

>>> Would you still say that the above costs are worth the 
>>> nearly-intangible gain?
>>
>> "nearly-intangible" is wrong. Library code is code which isused by  
>> (hopefully) millions of people, writing millions ofapplications,  
>> running for millions of hours, on millions ofsystems, creating  
>> thousands of processes, etc..  In short, alittle effort now pays  
>> massive dividends over it's lifetime.
>>
>> So, yes, IMO the costs shown above are worth the resultinggains.
>>
>> D is constantly being compared to other languages on the basisof  
>> performance, so it's clearly an important aspect of D'ssuccess.
>>
>> Library code needs to work first time and work well or peoplewill roll  
>> their own wasting time, energy and in many casesgetting some aspect of  
>> it just plain wrong.
>
> But once again, you speak in vague terms.

The initial point was a vague one, not a specific one.  Manu wasn't  
attempting to block std.process, he had a general concern which I share.

> Consider the following hypothetical decisions and outcomes:
>
> 1. std.process is left at is. One user is angry / turned awaybecause it  
> performs 0.1% slower than it can be.

It very much matters *who* that 1 user is.  And, the count may be higher,  
and we might never "hear" from these people as they find other solutions.   
We're lucky that some people who try D and have issues tell us about them,  
they may be 5% of the total for all we know.

> 2. std.process is rewritten to minimize allocations. Codecomplexity goes  
> up, new improvements are challenging to add; bugspop up and go unfixed  
> for a while because fewer programmers arequalified or willing to commit  
> the effort of making correctfixes. More people are angry / turned away  
> from D because itsstandard library is buggy.
>
> Of course, the above is an exaggerated illustration.

Indeed, you've downplayed point #1 and exaggerated point #2.  In reality  
the suggested improvements would add only very minor complexity and  
prevent none of the current crop of contributors from working with/on  
std.process.

> But would optimizing all code left and right really make more D users 
> happier?

Yes, as well as the users of their applications.  True, none of them will  
even realise they could have been less happy, so none of them will realise  
the effort that went into it, but all of them will be better off.

> There's also the question of priorities. Would you rather thaneffort is  
> spent on optimizing std.process (and dealing with allthe fallout from  
> any such optimizations), or working on somethingthat is acutely missing  
> and hurting D?

Add the missing items, without a doubt - which is why no-one is suggesting  
blocking std.process over this issue.

>> D is a systems programming language, there is hope that it will 
>> penetrate a wide range of systems and environments - sure inmany cases  
>> a little bit of memory use or performance loss isunimportant, but for  
>> many it will be the decisive factor whichmakes D unusable there.
>
> This is surely an exaggeration.

Why?

There exist platforms and environments where memory and performance are  
concerns, if the D standard library code is not "careful" in it's use of  
both then it will be less suitable than C (for example) and so D will not  
penetrate those platforms.

Manu is using D for games development on modern high-end gaming PCs and he  
is still concerned with memory and performance.

So, there's 2 very different cases where memory and performance are still  
a concern, and .. if they become too much of a concern another solution  
will have to be sought.. and that's bad news for D.

> D does not attempt to please everyone out there who is choosing a 
> programming language for their next project. There is no suchlanguage,  
> nor can one exist. One has to accept that D has anumber of goals, none  
> of which are absolute, but merely pointtowards a certain, but not overly  
> specific, point in themultidimensional matrix of trade-offs. D never was  
> aboutachieving maximum performance in all possible cases.

All true, but performance is one of D's top draw cards:

<quote>The D programming language. Modern convenience. Modeling power.  
Native **efficiency**.</quote> (**emphasis mine**)

So, it behoves us to make sure the standard library keeps that in mind.

R