On Tuesday, 9 January 2024 at 19:19:51 UTC, H. S. Teoh wrote:

> And this is where we have trouble: Walter and Andrei are technical geniuses, but the way they interact with the community is, how do I put it, lackluster.  This thread is a prime example: when confronted with a full-out fork of the project, any manager in charge would at least be, to put it mildly, *somewhat* concerned, and at least try to engage with the issues being presented, even if it is to disagree.  However, here we have dead silence on the core dispute and instead lots of activity on a tangential technical issue.  OT1H it shows where Walter's strength is -- grappling with technical issues -- but OTOH it also leaves a lot to be desired on the management side of things.

I'll point out that there's a third leader that nobody's expecting to interact with the community. To the point that nobody's even bringing him up or asking why he doesn't respond to the fork. He's also strong technically, but interacting with random people and building a community are not exactly his strong suit. I think the problems run deeper than Walter being slow to give feedback or being conservative about accepting language additions.

On Tuesday, 9 January 2024 at 21:56:55 UTC, Walter Bright wrote:
> On 1/9/2024 10:23 AM, Abdulhaq wrote:
>> * Languages such as D need a BDFL who spends more time managing and orchestrating developments than cutting their own code.
>
> The trouble is there are some coding problems that only I can resolve. For example, nobody else is crazy enough to have embedded a C compiler into D. Heck, I thought it was a crazy idea for a couple decades.
>
> Would anyone else have implemented an ownership/borrowing system for D? It exists as a prototype in the compiler now, though it's been fallow for a bit as too many other things are happening. I know its design is controversial (Timon doesn't like it at all!), and it hasn't yet proven itself.

If you contribute this work to the fork, you'll have folks to try it out and provide feedback, and you won't have to add experimental flags to the compiler or mess with the compiler at all.

On Tuesday, 9 January 2024 at 21:56:55 UTC, Walter Bright wrote:
> On 1/9/2024 10:23 AM, Abdulhaq wrote:
>> * Languages such as D need a BDFL who spends more time managing and orchestrating developments than cutting their own code.
>
> The trouble is there are some coding problems that only I can resolve. For example, nobody else is crazy enough to have embedded a C compiler into D. Heck, I thought it was a crazy idea for a couple decades.
>
> Would anyone else have implemented an ownership/borrowing system for D? It exists as a prototype in the compiler now, though it's been fallow for a bit as too many other things are happening. I know its design is controversial (Timon doesn't like it at all!), and it hasn't yet proven itself.
>
> Many bugzilla issues get forwarded to me because nobody else seems to want to or are able to fix them.
>
> I've been slowly working on restructuring the front end so it is more understandable and tractable.
>
> I'm also very impressed with how far along Razvan and Dennis have come in being able to deal with difficult compiler problems.

Nobody is asking you to solve all the problem, I'm here for almost 20 years now, following and actively using (taking unfair advantages?) of D at work.

I've the impression that things are slowly moving on, and right now it's a pivot point for D history, just like as it was turning it open source, or the joining of Andrei and the first book, something similar.

You, Walter, created an incredible useful language (and a beautiful one!), so you have all my respect, it's clear in my mind how big the effort was in the past, and still it is: I've followed your effort since pre D1.

A fork can revitalise D, as Rust, and the flourishing of other new modern languages shock C++ , I think all the best about Adam, he is able to produce an incredible amount of code that actually DO the job.  I will not bet against the failure of OpenD, ironically Adam is VERY pragmatic.

And pragmatism was what first attracted me to D,  pragmatic view about problems: we have a big problem right now, so let's try to find a way to resolve it in a pragmatic way.

The D programming language does not need another Kenji event. D can't loose talented contributors just for the sake of "formatting": that was an incredible fool example of total nonsense, and the net loss for the community was terribly hight.

Pragmatically, again, D core members need to sit down (hopefully in front of a good beer!) and find an escape path. My humble suggestion, from what I see and I've seen in the past.

Literally NOBODY is on DIP 1027 camp. This means that EVERYONE sometimes is wrong, also if not convinced at all. There should be a mechanism that triggers in that case: “Logic clearly dictates that the needs of the many outweigh the needs of the few.", How am I to contradict Spock? With this mechanism in place, DIP DIP1036e should be merged. Yes, the same happened with safe by default.

Also, add a third person to the Walter/Atila duo, a member of the community with better focus and understanding about the attitude of the community, but also a strong tech view of D.

My ideal choice would be Steven (but hey, maybe Steven is horrified by the idea), as Mike is already doing a great job in his role.

As someone said, a modest proposal.

/P

On Tuesday, 9 January 2024 at 22:04:52 UTC, Lance Bachmeier wrote:

> I'll point out that there's a third leader that nobody's expecting to interact with the community.

Stupid question: Is there a page on dlang.org where people and their roles are mentioned? A who is who of the Dlang team …

On Tue, Jan 09, 2024 at 11:14:56PM +0000, Paolo Invernizzi via Digitalmars-d wrote: [...]
> A fork can revitalise D, as Rust, and the flourishing of other new modern languages shock C++ , I think all the best about Adam, he is able to produce an incredible amount of code that actually DO the job. I will not bet against the failure of OpenD, ironically Adam is VERY pragmatic.

If anyone hasn't tried out Adam's arsd.* libs yet, I'd highly recommend trying them out.  Especially check out arsd.jni, which is so awesome it almost makes working with Java palatable to me again. As far as I'm concerned, Adam could well be the D library analogue of Kenji.  If anybody can make a D fork succeed, he'd be one of the prime candidates. Personally I don't always agree with him, but there's no arguing with his results.


[...]
> The D programming language does not need another Kenji event. D can't loose talented contributors just for the sake of "formatting": that was an incredible fool example of total nonsense, and the net loss for the community was terribly hight.

The loss of Kenji was one of untold proportions.  He was one of the major drivers of D development back in the day -- we'd be discussing about some hypothetical feature in the forums, debating the pros and cons, and Kenji would suddenly pop up with an implementation that addressed all concerns, had a neat, consistent design, and worked as expected.  It was phenomenal.  D wouldn't be halfway where it is today without him. He literally contributed about 1/2 of the entire dmd codebase when he was still with us.

To lose such a major contributor over some petty squabble about formatting is, well, I'm at a loss of words for it.  If one can't see this tragic catastrophe for what it is, then I really don't know what else to say, it's a lost cause.


> Pragmatically, again, D core members need to sit down (hopefully in front of a good beer!) and find an escape path. My humble suggestion, from what I see and I've seen in the past.
> 
> Literally NOBODY is on DIP 1027 camp. This means that EVERYONE sometimes is wrong, also if not convinced at all. There should be a mechanism that triggers in that case: “Logic clearly dictates that the needs of the many outweigh the needs of the few.", How am I to contradict Spock? With this mechanism in place, DIP DIP1036e should be merged. Yes, the same happened with safe by default.

Exactly. It's the same pattern repeated over and over throughout the years.  It has not changed one bit.  If it was once, we could call it a mistake.  If it was twice, we could blame it on some thing or another. But now that it has happened repeatedly for more than 10 years, without fail, even the most stubborn among has to admit that something isn't going right, and it's fundamental.  We should not fool ourselves any longer. D isn't going to get past this blockade until something radical changes.

It's not a question of decisions that I don't like or that didn't go my way, or anybody else's way.  Many design decisions could go either way, there's always pros and cons and sometimes you just have to arbitrarily pick one way or the other, and no matter which choice you make, somebody will be unhappy. That's expected, and that's not the problem here.  The problem here is the persistent, recurring, and consistent act of rejecting something *without having bothered to understand what it was in the first place*, topped up with the outright unwillingness to be made to understand.  I've been trying not to use the word disrespect directly, but there is really no nice way to put this.  Just read the current discussion on DIP1036e in the other thread, it's there for all to see.  As long as this continues, we're not getting past this blockade.  That's all there is to it.

This is why I'm extremely interested in this fork, even if I don't always agree with Adam's motivations and decisions.  This could be the event that will shake things up enough to break D through the blockade. It would be the biggest tragedy if D continues to languish and never reach its full potential.  It's no longer just about DIP1036e, or safe by default (which failed over a seriously minor quibble, totally disproportionate to the benefit that we would have reaped had the leadership relented on that minor point), or a whole bunch of other technical issues.  What's at stake is the long-term viability of D.

I've said before and I say again: this issue here is not technical, it's social.  Until something changes on that front, D is going to be stuck behind that blockade indefinitely.  OTOH, maybe that will be for the best. Let the current D continue to stagnate, and let Adam's fork thrive.  Time will prove which way was the right way forward.  A radical change must happen one way or another; the status quo cannot continue anymore.


> Also, add a third person to the Walter/Atila duo, a member of the community with better focus and understanding about the attitude of the community, but also a strong tech view of D.

What we sorely lack is a person with better social skills than your typical average D geek (including yours truly -- I do not exclude myself from disqualification).  In spite of all our hopes to the contrary, not every problem can be solved with technical means; that's just not how things work in real life.  Somebody in the leadership needs to have the social skills to interact with the community, and interact successfully, otherwise this stalemate will only be prolonged.  Like it or not, that's just the harsh reality we have to face.


> My ideal choice would be Steven (but hey, maybe Steven is horrified by the idea), as Mike is already doing a great job in his role.
[...]

If Steven would be nominated, I'd support him. ;-)

OTOH, based on the reactions I'm observing on this thread, the chances of a breakthrough are rather low, even if Steven were to be added.  In spite of myself I'm seeing Adam's fork as being the more promising alternative at present.  Time will tell where it will lead.


T

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

On 1/9/2024 3:14 PM, Paolo Invernizzi wrote:
> I've the impression that things are slowly moving on, and right now it's a pivot point for D history, just like as it was turning it open source, or the joining of Andrei and the first book, something similar.
> 
> You, Walter, created an incredible useful language (and a beautiful one!), so you have all my respect, it's clear in my mind how big the effort was in the past, and still it is: I've followed your effort since pre D1.
> 
> A fork can revitalise D, as Rust, and the flourishing of other new modern languages shock C++ , I think all the best about Adam, he is able to produce an incredible amount of code that actually DO the job.  I will not bet against the failure of OpenD, ironically Adam is VERY pragmatic.
> 
> And pragmatism was what first attracted me to D,  pragmatic view about problems: we have a big problem right now, so let's try to find a way to resolve it in a pragmatic way.

I appreciate your thoughts on this. One issue is that, as D has become more complex, it also is inevitably going to move more slowly. A lot of effort is needed to keep from breaking stuff and to try not to box ourselves into a corner with a feature-of-the-moment. (Autodecoding was a box we put ourselves in, arrggh.)

For example, quite recently, there was a storm on the n.g. about not fixing existing problems, but instead adding new features.

We decided to stop adding new features for a while, and concentrate on backing and filling what we'd already done.

For example, I posted a spec on pattern matching and option types, but that is on hold until we get some more backing and filling done.

As an example of backing and filling, we merged several PRs that re-enabled deprecated features, in order to better support older code. We've amended our mission now to do the best we can to not break existing code. It's kind of an invisible feature, it doesn't generate any excitement, its effect is just in not making people mad (!).


> The D programming language does not need another Kenji event.

There's a non-public story about what happened with Kenji. He has chosen to not leave an explanation, and I respect that by reciprocating. I hope he has done well and prospered since leaving us.

P.S. I don't reject proposals just because they come from Adam. I recently approved his standalone constructor proposal, because he competently addressed all my issues with it.