@simontatham This casual churn in tooling erodes trust in the system the tool exists in, not just in the tool itself. We need to be able to depend on our tools, to be able to reason about them, to know what their limitations are, and how they fail. We have a mental model of them and as long as changes are gradual and evolutionary it's relatively easy to adapt and to maintain trust.

We're getting to the point that a generation or two of developers have thoroughly discarded notions of trust and consent. They are frustrated with caring about other people. Or maybe it wasn't that big of an issue because systems were smaller and balkanized - uses weren't as diverse and there was a tighter community that meant systems didn't need to change often and that changes served the majority of users.

What's darkly amusing is that I have substantially less trouble recovering abandoned 50-year-old Fortran code than I do 6-month-old Python. For all its many limitations and flaws, Fortran takes backward compatibility very seriously, deprecating misfeatures over decades yet still managing to add major features. Python is a disposible language for disposable programs and disposable programmers.

Who does disruption serve? In the past 15-20 years my answer has generally been "not me". Not out of being hidebound or change averse but because my needs are fairly stable. Most of the problems being solved are problems I don't face. So much seems like disruption is for disruption's sake not out of any actual (community) need. Stable means old and old is bad and anyone who argues can be safely ignored.