We are forking D

[H. S. Teoh]

On Tue, Jan 09, 2024 at 06:23:47PM +0000, Abdulhaq via Digitalmars-d wrote:
[...]
> A few birds-eye view observations of my own:
> 
> * D is Walter's baby and his life work. As other people come and go,
> as they are wont do with any project such as D, he knows he will be
> left holding the baby and maintaining it. That is why he will not
> accept PRs unless they appeal to his taste and he is confident they
> are a net positive and don't complicate the whole thing too much. I
> fully expect Adam to start behaving like this BTW, for the same
> reasons.

Adam is already doing this. There's been a ton of proposals and ideas,
and while he hasn't straight out turned down anyone yet, he *is* already
warning that everything will be evaluated based on whether they bring a
net positive, or will simply be too costly to be worth the effort.

There are nuances to such management, though. Take Linux for example.
Linus still calls the final shots for whatever makes it into the kernel.
But he knows how to delegate -- he has not a small number of trusted
delegates that look after major subsystems, and he trusts them to make
decisions of their own without always needing to go through him. He can
still override their decision if he sees something obviously wrong, and
he can (and has) reverted stuff that he feels were wrong after the fact.
But the key point is that he does not demand that every decision go
through him, and that's what keeps him from becoming a bottleneck.

We do have something similar in D to some extent, but nowhere near the
point where Walter ceases to become a bottleneck.  The whole process
could use more streamlining. A LOT more.


> At some point in the history of D it was realised there needed to be a
> way to make the evolution of D more democratic. This is when DIPs were
> introduced. However, Walter's reluctance to accept DIPs made them an
> infamous time sink and often a dead end.In my view this is not
> unreasonable but it's certainly annoying for would-be contributors.

It's definitely reasonable. Walter is the one who decides what goes into
D and what doesn't, so naturally he needs to be fully convinced of the
value of a DIP before he will accept it.  His standards are naturally
high -- D being what it is, it could hardly be otherwise.  Unfortunately
he has also shown time and again that he often misunderstands exactly
what is being proposed, and appears reluctant to take the time to
understand the proposal before shooting it down.  It's his prerogative,
of course, but it does make working with him a rather challenging task.
One that not many would-be contributors would be willing to go through.


> * Languages such as D need a BDFL who spends more time managing and
> orchestrating developments than cutting their own code. However, if
> often doesn't work out like that. Walter becomes a bottleneck and
> until he steps back from CTO, he will remain so.

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.


> * In the python world, the standard library is considered to be the
> place where libraries go to die, because the API becomes frozen. I
> agree with that take, and would concentrate on having a good packaging
> system where it's easy find the popular and well maintained libraries
> for given tasks e.g.  XML, json, database clients etc. Forget about
> fighting to get stuff into Phobos, it's too hard and a fool's errand.
[...]

But why does it have to be this way?  Why must the standard library be
held to such unattainable standards that nobody but a rare few could
reach it?  Maybe it's time to reconsider how it is managed.  Why can't
it be open for the community to maintain?  Delegate each major module --
std.json, std.xml, std.db (hypothetical), etc., to one or two competent
people who are enthusiastic about it and who can maintain it long term,
then take your hands off and just let them do their job. Micromanagement
helps no one and only hurts in the long term.  People need to earn their
trust, it's true, but once they've earned it, they also need some room
to do what they do, rather than be stifled by onerous demands or
unreasonably high standards.

I'm not saying this is a silver bullet that will solve all D's problems,
but why not give it a try and see?


T

-- 
The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!