We are forking D

[Paolo Invernizzi]

On Wednesday, 10 January 2024 at 00:29:38 UTC, Walter Bright 
wrote:

> 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.

The point is not the complexity of the language, or the moving 
velocity, It's good that actually D is in "let's fix stuff" phase 
of life. The point is not either the eternal "break / don't 
break" my code war.

Contributors are having an hard-life, that's the point. You 
repeated multiple times over the years that you excel in the 
technical field (like Andrei, or Atila), but it's more difficult 
to you to handle other human related management.

That's especially true when you fell in love with your idea, you 
literally start arguing with "your idea glasses", it's really 
clear in the thread about DIP1027 vs DIP1038e on SQL, you are 
arguing there with DIP1027 glasses on. It's not your specific 
fault, we are human, we behave sometime like that.

Let's come back to pragmatism:
- everyone thinks DIP1038e is far better than DIP1027
- you are not convinced, but hey, we are human being, maybe you 
are wrong.

What's the solution? Simple, recognise that! You grown a really 
talented group of people, so trust them! We are talking about a 
"language" feature, we have Timon onboard, with a raised thumb on 
that, trust his judgement!

There should be a way to simply trigger some procedure in such a 
cases, put onboard someone with that role: tap on your shoulder 
about that.

I'm also adding around auto-decoding, and the box we put 
ourselves in, that in that case there was no unanimous consensus, 
and a real unicode expertise was lacking to the designer at that 
time: it was a different story, that of course can be corrected.

> 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 (!).

I will not discuss too deeply about that, because I see a clear 
dichotomy in trying to keep things simple in the compiler because 
it's growing too complex and big and really no-one understand it 
fully (cough cough CTFE), and trying to keep every historical 
feature inside it, while evolving: it's an herculean effort, so 
I'm skeptical about that.

>> 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.

It's good to know, thank you for the clarification, that's 
refreshing indeed.

> 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.

I've no doubt about that, you are a serious and ethic person.

/P