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