On Wednesday, 10 January 2024 at 00:05:10 UTC, BlueBeach wrote:
> 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 …

Not sure. Walter and Atila Neves are "co-maintainers" of the language. The D Language Foundation officers are here: https://dlang.org/foundation/about.html The attendees of the most recent foundation meeting are listed here: https://forum.dlang.org/post/kcokzqxwdgtwvigqcrsi@forum.dlang.org And I think this is the list of everyone that can commit: https://github.com/orgs/dlang/people?page=1

On 10/01/2024 1:29 PM, Walter Bright wrote:
>     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.

When it comes to leadership changes, even if the position was informal (like with Kenji), its important to make a statement otherwise it can lead to tensions like it has done here.

This is the first time I have seen suggested that it isn't just a disagreement that lead to him leaving.

Quite often the details don't matter. What matters is the intent and the intent up to this point has appeared to be of being insulted.

On 10/01/2024 9:23 AM, Walter Bright wrote:
> On 1/8/2024 11:42 PM, Richard (Rikki) Andrew Cattermole wrote:
>> On 09/01/2024 8:40 PM, Richard (Rikki) Andrew Cattermole wrote:
>>> Is equivalent to:
>>>
>>> "pr\efix"
>>
>> If you use a markdown viewer (like myself) this is probably rendering out to be one backslash.
>>
>> It is meant to be two, as you need to escape the backslash to get into the value rather than trying to escape the e.
> 
> Oh, ok. That explains it.

I'm glad that we have resolved this line of misunderstandings.

It was getting silly, given that you would've wrote the code that handled this very thing and it was easy to see what was the case if you read the PR ;)

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

On Wednesday, 10 January 2024 at 10:40:51 UTC, Paolo Invernizzi wrote:
> Let's come back to pragmatism:
> - everyone thinks DIP1038e is far better than DIP1027

This isn't strictly true.

Some people like me don't care at all don't have time to read DIP and arguments, and trust the core team to choose for them. It's called having someone responsible for the design.

I'm in the camp of people fed up hearing about string interpolation for the last 3 months, and all the drama surrounding it. I'd rather not have string interpolation than just hearing about people complaining for months. Because this is what happened and at this point I can very well live without variables in quotes.

That's from seeing the leadership fence off bad ideas since years and years.
A lot of the times, about the right decision was taken.
It's painful seeing people becoming ever more demanding of open-source projects.

And I remember very well this community to be against introduction of @nogc, of UDAs (there was massive backlash), of -betterC, of memory-safety... including me.

On Wednesday, 10 January 2024 at 11:24:29 UTC, Guillaume Piolat wrote:
> On Wednesday, 10 January 2024 at 10:40:51 UTC, Paolo Invernizzi wrote:
>> Let's come back to pragmatism:
>> - everyone thinks DIP1038e is far better than DIP1027
>
> This isn't strictly true.
>
> Some people like me don't care at all don't have time to read DIP and arguments, and trust the core team to choose for them. It's called having someone responsible for the design.
>
> I'm in the camp of people fed up hearing about string interpolation for the last 3 months, and all the drama surrounding it. I'd rather not have string interpolation than just hearing about people complaining for months. Because this is what happened and at this point I can very well live without variables in quotes.
>
> That's from seeing the leadership fence off bad ideas since years and years.
> A lot of the times, about the right decision was taken.
> It's painful seeing people becoming ever more demanding of open-source projects.
>
> And I remember very well this community to be against introduction of @nogc, of UDAs (there was massive backlash), of -betterC, of memory-safety... including me.

What was meant obviously is: everyone who cares, had time to read DIP and arguments, and obviously trust the core team is on DIP1038e. If you don't care, well, that's fine.

I care, for example, because that would be an improvement in my company codebase.

But, again, the point under discussion is different, and Theo explained it well in his posts in this thread, don't focus yourself on the current specific case in string interpolation.

/O