It is the year 2020: why should I use / learn D?

rikki cattermole rikki at cattermole.co.nz
Sun Nov 25 14:20:25 UTC 2018


On 26/11/2018 3:04 AM, Chris wrote:
> On Sunday, 25 November 2018 at 13:04:41 UTC, rikki cattermole wrote:
>> On 26/11/2018 1:58 AM, Chris wrote:
>>> Guess why - and this speaks volumes - Johnathan M. Davis couldn't be 
>>> bothered to put dxml through a review process? Johnathan told us that 
>>> he wasn't "too enthusiastic" about it. Why wasn't the new std.xml 
>>> ever reviewed + accepted back in the day?
>>
>> If you're referring to std.experimental.xml, simple it was horrible 
>> code that wasn't complete and I did try to improve upon it. It just 
>> wasn't good D code. It wouldn't pass the review even if feature complete.
> 
> I don't know if it's the same code that was written for std.xml(2). But 
> why does it take so long to even reject something? Normally you would 
> say "Not good enough" and you'd announce that you need a better module 
> (with specs). Or why not take Jonathan's stuff (which I understand is 
> very good) and integrate it without him having to "push it". Successful 
> companies do that. They take promising stuff, clean it up and improve 
> it. You cannot wait until a volunteer has got it "perfect". It might 
> happen that you have something that's 90% there and then it's just 
> binned / abandoned, because the volunteer didn't put in the last 10% . 
> And then the volunteer is to blame. And maybe the poor volunteer 
> couldn't finish the work, because s/he had to wait for feature X to be 
> implemented.

It doesn't matter who does it. Its still all volunteer work even if 
there is a bit of compensation to go with it.

Jonathan's xml library is good within its scope. But it definitely isn't 
xml compliant because its scope says so. There is nothing wrong with 
this, but there are problems for this to go into Phobos as it is today.

We have been bitten in the past by code who wasn't scoped properly. So 
it should be a lot harder to have things accepted. Just a shame we don't 
really have the money to throw at a team to do libraries like this. To 
give people the options they need to both fit with D and with their 
external requirements (like specs).


More information about the Digitalmars-d mailing list