What's wrong with stability, LTS, and not fixing bugs for "compatibility".

Mathias LANG geod24 at gmail.com
Fri Oct 9 10:35:40 UTC 2020


On Thursday, 8 October 2020 at 10:37:22 UTC, FeepingCreature 
wrote:
> There's recently been discussion of how we can avoid breaking 
> people's code in the process of fixing bugs. I think this 
> approach is fundamentally wrongheaded. Sure, deprecations are 
> good if you can get them, but it should never happen that a bug 
> is unfixed because code depends on it.

I used to think that way. I don't anymore. What changed ? I ended 
up being on the receiving end.
It's fine to "move fast and break things" as long as the people 
breaking things are the people who will have to fix them. The 
cost, or burden, is on the same people, and it's those people 
decision what cost they want to shoulder.
But if the people suffering from the change are not the one 
benefitting from it, then you are just shifting the cost, and 
those people will eventually leave for a vendor that does not 
shift the maintenance cost on them.

Does no one remember when every single D release was a breaking 
change?

> I think this is to some extent an inherent problem with the D 
> *forum.* In Github and other forum software, you can give 
> upvotes, thumbs-up or likes to posts as a way of signalling 
> agreement. The D forum, due to its NNTP heritage, does not have 
> this capability. This severely hurts us in cases like the 
> named-parameter DIP or string formatting DIP, where even if the 
> great majority of D users are in favor of it, they will still 
> have *less to say* about their favor because agreement simply 
> has a smaller rhetorical surface than disagreement - you can 
> disagree in many more ways about many more things than agree. 
> As such, in a purely volume-driven discussion as you will see 
> on these forums, disagreement will always loom large. The 
> preview feature process is a small bulwark against this, by 
> allowing people to gather experience with a feature *without* 
> having first convinced or at any rate outlasted nearly every 
> naysayer on the forums, which is why the misunderstandings 
> about -preview=in, even from people like Andrei, are so 
> worrying to me. In my opinion, D does *not* have too many 
> breaking changes; D has *far too few* breaking changes. When I 
> can switch from 2.090.1 to 2.094.0 and often only get warnings, 
> I'm more upset than happy - what has gone wrong? Have we as a 
> language reached perfection? (We have not.)

Well, your first paragraph mentions code depending on bugs, while 
the second mentions purely additive features. I don't think the 
purely additive features have been held back by an abundance of 
conservatism, but more by inertia, which is another problem.

I however strongly agree with your feeling w.r.t. rhetorical 
surface of agreement vs disagreement. Another thing to keep in 
mind is that a minor, and very specific portion of D users are on 
the forums. I'm sure it's obvious to you, as I would be ready to 
bet than less than 10% of the D developers in your company are on 
the forums - as was the case with Sociomantic.

Regarding v2.090.1 => v2.094.0, I'm very happy that I don't get 
anything else than deprecations, and sometimes warning. It means 
that the libraries I use, which haven't been touched for years 
will not randomly break.

As much as I love to contribute to D, and as much as I've been 
involved over the years, working on D doesn't generate income for 
me. Building software for my company does, and D is just a means 
to an end. It so happen to be the best tool for the job, but if 
it wasn't, I'd use something else. Hence, the more things are 
shifted on me by breaking things, the less I can do my job, and 
the less D is an efficient tool.

> And no, big separations between major revisions such as LTS 
> versions are not a solution, they'd be contributing to the 
> problem. You think getting people to upgrade *right now* is 
> hard? Just wait until they have a reasonable expectation to let 
> upgrades lie for actual years. "If something is painful, do it 
> more often"; this aphorism is driven by the experience that 
> doing it less often makes it *more* painful. We risk ending up 
> in the D1 (Python 2, Perl 5) case where people don't update at 
> all.

This is an excellent case of:
https://upload.wikimedia.org/wikipedia/commons/9/98/Survivorship-bias.png
All languages have major revision and provide stability. Rust has 
editions, Go has forward compatibility, C++ and C do their own 
slow thing, etc...
Having every upgrade break your code is a great way to ensure our 
users don't return.

> But that's not my biggest objection. This is: the purpose of a 
> language is the code that people write in it. Are we 
> acknowledging that most code in D has already been written? Are 
> we giving up on growth? Are we saying "the level of popularity 
> that D has currently reached is probably at or beyond the peak 
> of usage"? Because if not, if we think that most code written 
> in D is still to come, then we are harming people's future 
> experience with D at the expense of not harming legacy code. I 
> think this is a self-fulfilling prophecy that will kill the 
> language.

I don't see any hint that people are not willing to improve the 
language. I must admit I was a bit discouraged by the reaction I 
saw to `-preview=in` in the forum, as opposed to the discussions 
I had before / the reactions on Github, and had a mild case of 
"this is why we can't have nice things". Yet, the flag is still 
there, and looking back at what happened over the last two years, 
I do not see a stagnating language.


More information about the Digitalmars-d mailing list