On 1/16/2024 6:38 AM, Paolo Invernizzi wrote:
> I'm referring to delegation for _judgements_ on specific aspect of D ecosystem: we are seeing it right now, an incredible amount of effort spent by a lot of people to "justify" why CT string interpolation is not a 'nice-to-have'.

Both proposals can do CT string interpolation.

There are misunderstandings about both proposals.

I suspect if we all sat down in a room together, we'd have it resolved within an hour.


> The net gain for _everybody_ , Walter included, would have been to simply delegate that specific judgement to Timon

I've never caught Timon in a technical error, he's a genius as far as I can tell! But we disagree now and then on the value of various inevitable tradeoffs. This stems from our different backgrounds.

On Tuesday, 16 January 2024 at 20:18:00 UTC, Walter Bright wrote:
> I suspect if we all sat down in a room together, we'd have it resolved within an hour.

While I’m not sure whether this would work out in practice from the organizational perspective, it sounds like a great idea.

On 17/01/2024 8:50 AM, Walter Bright wrote:
> On 1/16/2024 12:23 AM, Richard (Rikki) Andrew Cattermole wrote:
>> However on that topic, I was going to do a Unicode talk for DConf Online this year, but alas that kinda depended upon UAX31 identifiers, and you haven't been too keen to approve that line of work so I haven't done it.
> 
> I have actually approved it. My mistake it was not properly communicated to you.

The updated plan was not as you never replied. The earlier plan of removing non-starters was (but that is a breaking change and strategy surrounding that changed before I could implement it fully).

https://github.com/dlang/dmd/pull/15307#issuecomment-1620636247

I'm double checking that we are meaning the same thing. Regardless, breaking change prevention means I need to check in with you about how to move forward.

>> Now if only I could convince you about having reference counting... that's another lesson that came from it. Good chance I'm going to have to drop DIP1000/scope if that cross behavior isn't resolved tbh. I can bare the pain, but I can't ask others to.
> 
> We've investigated ref counting several times, but never figured out a way to make it both efficient and memory safe.

That is not our job.

Efficiency is a problem for the backend to deal with (LLVM/GCC only). Doing it with copy constructors and destructors removes all possibility of ever optimizing it. They can't be elided, nor be communicated to the backend that this is what they are.

Such backends have the capability for other languages like Objective-C. We'd need to figure out how to tap into it, but it is there in some form.

Regardless it won't be any worse than what we have now. The only difference being is that we'll be able to encode that it is a lifetime mechanic in the type system allowing it to override scope and hopefully be key to helping get D classes working in -betterC (decoupling it from druntime is something I want to look into).

On 1/16/2024 12:24 PM, Elias (0xEAB) wrote:
> On Tuesday, 16 January 2024 at 20:18:00 UTC, Walter Bright wrote:
>> I suspect if we all sat down in a room together, we'd have it resolved within an hour.
> 
> While I’m not sure whether this would work out in practice from the organizational perspective, it sounds like a great idea.

It's happened before. It's one reason why our annual in-person conference is so valuable. Sitting around the same table, perhaps with a beer(!), works wonders.

On Tuesday, 16 January 2024 at 20:18:00 UTC, Walter Bright wrote:
> On 1/16/2024 6:38 AM, Paolo Invernizzi wrote:
>> I'm referring to delegation for _judgements_ on specific aspect of D ecosystem: we are seeing it right now, an incredible amount of effort spent by a lot of people to "justify" why CT string interpolation is not a 'nice-to-have'.
>
> Both proposals can do CT string interpolation.
>
> There are misunderstandings about both proposals.
>
> I suspect if we all sat down in a room together, we'd have it resolved within an hour.

Yeah, I know, I manage people since I was 25 and I'm 54 now: I've learned that nothing settles down misunderstandings better than having a beer.

>> The net gain for _everybody_ , Walter included, would have been to simply delegate that specific judgement to Timon
>
> I've never caught Timon in a technical error, he's a genius as far as I can tell! But we disagree now and then on the value of various inevitable tradeoffs. This stems from our different backgrounds.

Different backgrounds are valuables, especially since also you are genius in engineering, hey, a C++ compiler written by a solo man!

On Tuesday, 16 January 2024 at 10:06:47 UTC, Atila Neves wrote:
> If I can summarise my own opinions about contributions, it's that they're absolutely welcome, but that every change has trade-offs and each diff has to justify itself with positive ROI. Of course it's going to be frustrating to work for free and not have it pay off (it's happened to me multiple times), but it also can't be the case that the default is to merge PRs unless "there's a reason not to".
>
> My own perception is that we keep saying this, but maybe not? Perhaps we need to update the contributor guide.

With due respect, I think focusing on acceptance vs rejection of PRs is completely missing the point here.

People like Adam Ruppe and Sebastian Wilzbach understand perfectly well that not every contribution is going to be accepted. They don't leave just because they can't get their way. They leave because they feel *personally* disrespected and insulted in their interactions with D's leadership.

When their contributions are ignored, and they have to wait weeks or even months to get so much as an acknowledgement (let alone a review) from leadership  [1], they feel personally disrespected and insulted.

When their good-faith technical arguments are dismissed by someone "pulling rank" without addressing the actual points [2], they feel personally disrespected and insulted.

When they put time and effort into following the proper process for their contributions, only to see leadership turn around and ignore that process when it suits them [3], they feel personally disrespected and insulted.

I understand that you and Walter do not *intend* to insult contributors or to treat them with disrespect, but you need to recognize that, in practice, that's what you've been doing, and good intentions do not absolve you of responsibility for it. And you need to stop doing it, because if you don't, it's going to kill D.

The simple fact is, D needs people like Adam Ruppe and Sebastian Wilzbach more than those people need D. D's leadership cannot afford to insult and disrespect its contributors until they run out of patience and leave for greener pastures. And D's leadership *especially* cannot afford to cement D in the minds of *potential* contributors as a language whose leadership is disrespectful, unprofessional, and frustrating to work with.

OpenD was on the front page of both Hacker News and Reddit's /r/programming this week. What effect do you think that's had on D's reputation? On its ability to attract new contributors?

This fork should have been a wakeup call, but already, looking at this thread, I can see that the wrong lessons are being learned. This is not about whether or not PRs get merged. It's about giving contributors the respect and acknowledgement they deserve--not just with your words, but with your actions, your effort, and your time.

D is a great language, and a great community. All of us here, I think, want to see it succeed. Please don't let us down.

[1] https://github.com/dlang/dmd/pull/15715
[2] https://github.com/dlang/dmd/pull/12828
[3] https://github.com/dlang/dmd/pull/12507

On Tue, Jan 16, 2024 at 10:17:35PM +0000, Paolo Invernizzi via Digitalmars-d wrote:
> On Tuesday, 16 January 2024 at 20:18:00 UTC, Walter Bright wrote:
[...]
> > I suspect if we all sat down in a room together, we'd have it resolved within an hour.
> 
> Yeah, I know, I manage people since I was 25 and I'm 54 now: I've learned that nothing settles down misunderstandings better than having a beer.
[...]

Meeting in person solves 90% of communication problems.  Although online communication preserves the textual content of a message, it often fails to convey the emotional and implicit contents, and lacks facial / body language cues, which are equally important parts of human communication. Video communication is somewhat better in preserving the facial cue component, but often still lacks (most of) the body language.


T

-- 
Designer clothes: how to cover less by paying more.

On Tuesday, 16 January 2024 at 20:45:58 UTC, Walter Bright wrote:
> On 1/16/2024 12:24 PM, Elias (0xEAB) wrote:
> ...
> It's happened before. It's one reason why our annual in-person conference is so valuable. Sitting around the same table, perhaps with a beer(!), works wonders.

I work as developer in a pretty much one of biggest health care companies in my Country. We have developers scattered across all the country, so we do pretty much everything online. Last week we were having a problem with one system, we stayed all day long talking about it over text (Chat), I had a solution but unfortunately some teams wasn't understanding and miscommunication was occurring and some people was entering the chat later and asking the same things over and over.

The next day in the morning I was called again to explain the solution for a new team, then I asked everybody to go online (Video call).

Believe or not in less than 10 minutes we were finished.

This was not the first time this happened, where texts (Chat or e-mail) keep going around and nothing moves until we go online.

I think sometimes this group lack of this kind of thing. I even posted in another thread about String Interpolation that this should be resolved faster if you were online.

That's it,

Matheus.

On Tuesday, January 16, 2024 1:24:04 PM MST Elias (0xEAB) via Digitalmars-d wrote:
> On Tuesday, 16 January 2024 at 20:18:00 UTC, Walter Bright wrote:
> > I suspect if we all sat down in a room together, we'd have it resolved within an hour.
>
> While I’m not sure whether this would work out in practice from the organizational perspective, it sounds like a great idea.

Among other things, that's how we got the package.d feature. Daniel Murphy and I discussed it at length with Walter at dconf (either in 2013 or 2014) at a table in the hotel, because we were looking for a way to split up std.datetime without breaking existing code. And ultimately, package.d was the result. Who knows whether that would have occurred if we hadn't been able to sit down and discuss it in person like that. And I'm sure that there are plenty of other examples of stuff that's come out of dconf or other D meetups. That's just the one that comes to mind for me first.

- Jonathan M Davis

On Tue, Jan 16, 2024 at 11:20:59PM +0000, Paul Backus via Digitalmars-d wrote: [...]
> With due respect, I think focusing on acceptance vs rejection of PRs is completely missing the point here.

Spot on!


> People like Adam Ruppe and Sebastian Wilzbach understand perfectly well that not every contribution is going to be accepted. They don't leave just because they can't get their way. They leave because they feel *personally* disrespected and insulted in their interactions with D's leadership.
[...]
> I understand that you and Walter do not *intend* to insult contributors or to treat them with disrespect, but you need to recognize that, in practice, that's what you've been doing, and good intentions do not absolve you of responsibility for it. And you need to stop doing it, because if you don't, it's going to kill D.

Yes, this is exactly what I've been trying to say (unsuccessfully, it seems).  Thank you for spelling it out.  Hopefully in a clear enough way that the message gets through.

Because if this continues, D is indeed going to die.  It may be a slow, painful death, but it will die.  Die from long-time contributors finally deciding to throw in the towel.  Die from not being able to gain (and retain) new contributors to replace them.  And that would indeed be a huge tragedy.  D is a great language, and has so much potential.  For it to go to waste, because its leadership refuses to acknowledge and fix a social problem that has become glaringly, blindingly obvious to any unbiased observer over the past decade or more, would be a great tragedy indeed.


> The simple fact is, D needs people like Adam Ruppe and Sebastian Wilzbach more than those people need D.

Yes.  There's an entire series of contributors who, had they stayed, would have made a HUGE difference in D.  How many more do we need to lose before we wake up?


> D's leadership cannot afford to insult and disrespect its contributors until they run out of patience and leave for greener pastures. And D's leadership *especially* cannot afford to cement D in the minds of *potential* contributors as a language whose leadership is disrespectful, unprofessional, and frustrating to work with.

Exactly.  We're already having manpower problems.  Had been having them for a very long time now.  If this continues, in all likelihood it will get worse.  And may well reach the point where it will actually kill D.


> OpenD was on the front page of both Hacker News and Reddit's /r/programming this week. What effect do you think that's had on D's reputation? On its ability to attract new contributors?
> 
> This fork should have been a wakeup call, but already, looking at this thread, I can see that the wrong lessons are being learned. This is not about whether or not PRs get merged. It's about giving contributors the respect and acknowledgement they deserve--not just with your words, but with your actions, your effort, and your time.

+100.  This fork has never been about the string interpolation PR. Nor about some pet feature that got rejected.  All of that is only incidental. The REAL problem is the lack of respect and acknowledgement, not necessarily in word but certainly in action, that has accumulated over years, even decades, until finally the camel's back snapped.

To merely remove that one last straw and think that the camel is now OK, completely misses the point.  The remainder of the burden is still on the camel's back.  It won't take much before another straw is piled on and the camel's back will break again.  Soon there will be no more camels left, and D will be stranded, maybe forever, in the middle of the desert of obscurity with nowhere else to go.


> D is a great language, and a great community. All of us here, I think, want to see it succeed. Please don't let us down.
[...]

As others have already said, this is a critical juncture for D.  If the current leadership continues its present course, openD may very well become D's replacement.  Or it may not, and both will die.  That is also a very real possibility.

The best hope for D is really if the leadership could be reconciled with the openD folk, and both could work together to improve D.  Adam has told me personally that this would be the best outcome.  However, he is not holding his breath.  Please prove him wrong.  Because the other alternatives all suck.


T

-- 
People tell me that I'm paranoid, but they're just out to get me.