On 2024-12-19 05:13, Sean Whitton wrote: > On Sun 15 Dec 2024 at 11:21pm +01, Philipp Kern wrote: >> Or introduce some subtle bugs that get ironed out only when it sees >> usage. > > Indeed, but this work can end up being very costly. A lot of knowledge > might be built into the old code. Even if everything is well > documented > and there are comments in the right places, it's still easy to lose > something in the rewrite. > > Then you have to balance the reductions in complexity and excision of > features that weren't a great idea, against this risk of costly > regressions. Keeping the old program will often win. > >> In today's world the alternative is to remove the package - given the >> rather aggressive removals we see in testing, if not unstable. > > This seems like an overgeneralisation. For Perl, given their strict > stance to backwards compatibility, we can just keep it.
Assuming there aren't any other mandates that need to be applied to make the package fit for release or someone can be found to implement them. It's possible that there are fewer of them, but you still need someone to patch them when they arise. (The context of my take was the lack of maintainer (or maintenance).) I guess I agree very much with the point raised by Richard: "the people who wrote these scripts are no longer responding" (for one reason or another). As a mental exercise, substitute Perl with COBOL. It is very costly to maintain these days because the knowledge went away - and because the things are very load-bearing so that there is a lot of hesitance to touch things. And younger people (ironically, like me) did not grow up with it and thus have aversions. Keeping the old program will indeed win, because even incremental changes are frowned upon. I am fully aware that there is readable and well designed Perl that is easier to maintain than some of the more freestyle Perl cobbled together (e.g. without "use strict"). The better the environment around it (tests, test instances etc.), the more comfortable people will feel to make changes. Which I guess is a lesson for new software we write[1]. Kind regards Philipp Kern [1] I was amazed to see that snapshot has integration tests, for instance.
