A comment on the Medium version of last week’s article got to me:

I wish they’d just leave Perl static. Then we wouldn’t have to waste money retesting legacy Perl apps on the newest version every couple of years, in case new features we don’t want breaks code that’s been unchanged for years. […] Sometimes things should just be left to die gracefully.

William Smith

Programming languages, like all software, change to meet new challenges. Developers add new feature enhancements, users find bugs for them to fix, and occasional design errors need to be corrected. In Perl’s case, the Perl 5 Porters (the group of volunteers that develop and maintain Perl) have had an explicit backward compatibility and deprecation policy since 2011 that tries to protect the Perl user community from the breakage of old code while still moving the language forward. In short, they do their absolute best to minimize your testing and changes.

To that end, the Perl developers have done an amazing job presenting new syntactical features as only enabled when adding the appropriate use feature or use VERSION construct. If you do not add this code, the new syntax will not be enabled and your legacy code will not break. Incompatible changes, if there are any, are always documented in a release’s perldelta document (hint: it’s under the heading ​“Incompatible Changes”).

Given all this, it is a monstrous thing to demand an entire volunteer community stop enhancing their platform so that your particular applications can remain static while continuing to take advantage of the support policy generously offered for recent releases. If you need an unchanging platform, don’t upgrade it—and take all the responsibility that implies, such as the backporting of security fixes beyond the three-​year support commitment offered (again, gratis) by Perl’s developers.

You have no right to demand Perl stands still and ​“dies gracefully” any more than anyone has the right to demand that of you.