I recently had to maintain some new perl code. I didn't think it would be a big deal, but found a number of things I take for granted today that perl hasn't kept up with:<p>1) The perl cpan module doesn't resolve dependencies<p>2) The cpan module has parsing errors when passing in a list of CPAN packages<p>3) You have to manually grep your perl code to see what modules it depends on<p>4) Module installs take a long time since they can compile and unit test the code, unit tests can even make connections to the internet or try to access databases and fail, so you just have for force them to install<p>5) Non-interactive installs of CPAN modules requires digging in the docs and learning you need to set an env var to enable<p>6) CPAN modules aren't used that heavily and can have bugs that would be caught in wider used modules. (e.g. the AWS EC2::* modules don't page results from AWS so results sets can be incomplete, whereas the wider used boto lib works correctly and is better maintained.)<p>7) Perl devs don't think twice about shelling out to an external binary (that may or may not be installed)<p>8) Even if regexs are not needed, inevitably the perl dev will use them since that's the perl hammer, and it's hard to know what the intention is with regexes or what the source data even looks like<p>9) You have to manually include the DataDumper package to debug data structs<p>10) You have to manually enable warnings and strict check, it's not on by default.<p>Anyhow, I think we've made a lot of progress since the 1990s. :)
In my opinion the biggest problem with legacy code is understanding its implementation as someone who hasn't worked on it before. In a lot of cases it's not documented well and the original authors have already left, so there's no one to ask. You are left with reading code written by someone else, which takes a lot of time.<p>This is not Perl related, but I'm currently working on a developer tool that makes this part of the job easier. It's a source explorer for C/C++ named Coati that simplifies navigation within source code and thereby makes understanding the implementation faster and easier. <a href="https://www.coati.io/" rel="nofollow">https://www.coati.io/</a>
A softer phrase that might work better is "All Software is Experimental". It has less pejorative connotations, and could be a shibboleth among seasoned developers.
Legacy software is successful software. What's the point of building a program that will be discarded after a few months because its users fled to the next big thing? That just means more lines of code being written overall, needlessly.
I used to fantasize about having a code base I'd maintain for the next X0 years. Something like Dwarf Fortress, or hell, even TempleOS. Then I slap myself and come to my senses. Who knows how different coding will be 10 years from now? Do I really want to get married to something that's bound to be obsolete sooner rather than later?
We should all be so lucky as to write legacy code because the alternative is worse: code that is never deployed, or deployed only for a short time. A project and website I worked on for about 10 years was recently shuttered, and I am extremely proud of what that code did for the business which paid me.