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

FeepingCreature feepingcreature at gmail.com
Thu Oct 8 10:37:22 UTC 2020


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

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.

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.



More information about the Digitalmars-d mailing list