On 3/1/2019 1:38 PM, Paolo Invernizzi wrote:
> Oh Walter, this is soo plain wrong! I adopted D in my company, more than 15 years ago, exactly for the opposite reason...

I suppose there is always a counterexample :-)

But I do hope you found D to be good for your company.

On Friday, 1 March 2019 at 21:23:10 UTC, Walter Bright wrote:
> On a final note it doesn't matter to the DIP approval process how hard anyone works on the proposal, or how much time they spent on it, etc. **Only results matter **. By the same token, I don't expect anyone to care how much time I spend on D, I don't expect anyone to use D because people worked hard on it, etc. The only thing that matters is how good D is.
>
> It's a bit like the Olympics. Nobody cares how hard/long an athlete trained. Only that they win. Who would want it any other way?

I see, wise words... Now to hold someone at gun point to write a DIP..

On Friday, 1 March 2019 at 21:40:51 UTC, Walter Bright wrote:
> On 3/1/2019 1:38 PM, Paolo Invernizzi wrote:
>> Oh Walter, this is soo plain wrong! I adopted D in my company, more than 15 years ago, exactly for the opposite reason...
>
> I suppose there is always a counterexample :-)
>
> But I do hope you found D to be good for your company.

For sure! It was not good, it was great, and think about all the mess we cross in that 15 years of D development...

 I just hope for more pragmatism, like your way moving, and MORE vision.... just don't underestimate that...

Sincerely, Paolo

On Friday, 1 March 2019 at 21:23:10 UTC, Walter Bright wrote:
> When I get involved early in the DIP process, what happens is the author quits and leaves it to me to finish, which usually means doing 98% of the work.

This doesn't make sense.  If you leave feedback and the author quits you don't have to take over the work.  Let someone else take it over.  Even better, since you left feedback, the new owner can take your feedback and improve the DIP with it.  If no one takes it over, then the DIP isn't worth anyone's time and you've now saved a years worth of the author's and community's time from researching/revising and debating worthless DIP.

>
> Most proposals to improve process with D revolve around asking myself and Andrei to do most of the work. It just doesn't scale.
>
> The point of the DIP process is to mobilize the community to do the work, demand a high standard, and vet the work.

This is misrepresentation of what we are proposing.  We are not proposing that you "baby" each DIP through the whole process.  We are proposing that you stay involved along the process just like all the other reviewers.  This means that if you see a new DIP and it definitely will never get into the language, take a minute to respond immediately with why it won't be accepted.  Not every proposal will need your intervention either.  If you take a look at a DIP and it looks fine but needs some polish, let the community do that.  If you see a DIP and there's a question you can already answer such as a general direction it should take, then give that direction.  All we're asking for is feedback and direction from you.  Since you are the decision maker, you're the only one that can do this job.

What's worse is it sounds like you and Andrei are actually using the DIP process to go out of your way not to leave any feedback at all.  I have no idea why either of you would think this is a good idea.

>
> As mentioned before, this has been successful in the C++ community in that the standard of proposals has steadily risen. I've spoken with Mike Parker about picking out a couple of approved DIPs to be presented as a "gold standard" on how to do a DIP. We expect to replace them with better ones over time, to keep on raising the bar on quality.
>
> Having such examples makes it much easier to review a DIP and bounce it back as "not good enough".
>

The C++ standard is a good goal to work towards but trying to force it on a community that hasn't matured yet will not produce the results you want.  In my opinion, the DIP process should start with yours and Andrei's involvement and evolve naturally into what the C++ community has.  As the community interacts with you and Andrei on the proposals, certain people will start to stand out as those who can implement your standards and who have similar opinions as you.  Over time, you should find that you just don't need to spend as much time because your "lieutenants" will already be giving the feedback that you would have given.

Trying to force this heirarchy without the necessary foundation of transferring knowledge and expertise to the community will result in a "foundation-less" process where no one is able to know what you and Andrei want so in your eyes the quality suffers.  That's exactly what we are seeing today.


> ---
>
> On a final note it doesn't matter to the DIP approval process how hard anyone works on the proposal, or how much time they spent on it, etc. Only results matter. By the same token, I don't expect anyone to care how much time I spend on D, I don't expect anyone to use D because people worked hard on it, etc. The only thing that matters is how good D is.

Agreed.  We are not complaining about the amount of work.  We are complaining that there is no feedback to the work we are doing so we are "wasting work".  The "amount of work" is not a problem.  A large community with a good process can do amazing things, but with a bad process will just be a waste of everyone's time as it does not produce any results and takes everyone's work away from what could be productive tasks.

>
> It's a bit like the Olympics. Nobody cares how hard/long an athlete trained. Only that they win. Who would want it any other way?

Exactly.  With the current process everyone is doing alot of work and producing no results.  We are proposing to change the process not to save work, but to turn the work we are already doing into effective results.

On 3/1/2019 1:54 PM, Paolo Invernizzi wrote:
> For sure! It was not good, it was great, and think about all the mess we cross in that 15 years of D development...

That is wonderful news!

>   I just hope for more pragmatism, like your way moving, and MORE vision.... just don't underestimate that...

And I shall continue...

On 3/1/2019 2:01 PM, Jonathan Marler wrote:
> Exactly.  With the current process everyone is doing alot of work and producing no results.  We are proposing to change the process not to save work, but to turn the work we are already doing into effective results.

Dip1016 is not "no result". It's clear that rvalues to ref parameters is the way forward. I'm now writing the DIP for it.

On Friday, 1 March 2019 at 22:01:03 UTC, Jonathan Marler wrote:
> On Friday, 1 March 2019 at 21:23:10 UTC, Walter Bright wrote:
>> When I get involved early in the DIP process, what happens is the author quits and leaves it to me to finish, which usually means doing 98% of the work.
>
> This doesn't make sense.  If you leave feedback and the author quits you don't have to take over the work.  Let someone else take it over.  Even better, since you left feedback, the new owner can take your feedback and improve the DIP with it.  If no one takes it over, then the DIP isn't worth anyone's time and you've now saved a years worth of the author's and community's time from researching/revising and debating worthless DIP.

Case in point https://github.com/dlang/DIPs/pull/101#issuecomment-414803648

On Friday, 1 March 2019 at 21:23:10 UTC, Walter Bright wrote:
> On a final note it doesn't matter to the DIP approval process how hard anyone works on the proposal, or how much time they spent on it, etc. Only results matter. By the same token, I don't expect anyone to care how much time I spend on D, I don't expect anyone to use D because people worked hard on it, etc. The only thing that matters is how good D is.
>
> It's a bit like the Olympics. Nobody cares how hard/long an athlete trained. Only that they win. Who would want it any other way?

Oh come on.  This comparison makes no sense, the olympics are nothing like a programming language.  Specifically, a programming language is changing (it's not static)--which is very relevant considering we're talking about proposals to change it!  It absolutely is worth considering (and is considered) if a programming language you want to use is maintained by people who care enough about it to do their very best at maintaining it.  I have always balked at the assumption that a leader should *have* to love what they do, but there needs to be *some* sort of reason to believe that a project will be well-led, and that it will continue to progress intelligently as time goes on; passion and hard work are as good a reason as any.

On Saturday, 2 March 2019 at 03:51:00 UTC, Walter Bright wrote:
> On 3/1/2019 2:01 PM, Jonathan Marler wrote:
>> Exactly.  With the current process everyone is doing alot of work and producing no results.  We are proposing to change the process not to save work, but to turn the work we are already doing into effective results.
>
> Dip1016 is not "no result". It's clear that rvalues to ref parameters is the way forward. I'm now writing the DIP for it.

Out of all the things I said...you chose to respond to this?

I suppose I shouldn't be surprised.  If we've learned anything from the way you respond on the forums and the way you give DIP feedback, it seems to be a pattern of yours to ignore the major points of what someone writes, then respond to a minor part of it and think that's adequate.

I have a hard time seeing how someone can justify this behavior to themselves, unless you don't realize what you're actually doing; or maybe you just don't think a full response is worth your time.

Because of these poor responses we can never seem to get resolution.  We just keep arguing and coming back to the same things over and over.  I'd rather spend time my time programming but for some reason I still have hope that this community will get better.  Maybe I'm delusional.

On 3/2/19 4:50 AM, Jonathan Marler wrote:
> On Saturday, 2 March 2019 at 03:51:00 UTC, Walter Bright wrote:
>> On 3/1/2019 2:01 PM, Jonathan Marler wrote:
>>> Exactly.  With the current process everyone is doing alot of work and producing no results.  We are proposing to change the process not to save work, but to turn the work we are already doing into effective results.
>>
>> Dip1016 is not "no result". It's clear that rvalues to ref parameters is the way forward. I'm now writing the DIP for it.
> 
> Out of all the things I said...you chose to respond to this?
> 
> I suppose I shouldn't be surprised...

Meh, as long as he agrees "rvalues to ref parameters is the way forward" and is working on a DIP, I'm satisfied.