Should Perl die gracefully?
phoenixtrap.com
phoenixtrap.com
Hiring developers can help in the sense that they'll probably cover many of the needs but that runs into a problematic dynamic where companies contribute things they need but not contributing to unrelated maintenance, which can actually increase the amount of labor on the open source team being asked to review and merge their contributions if that doesn't remove some of the other work.
One argument is that Red Hat is a good compromise for many companies: your accountants can easily write a check for RHEL & support and they employ hundreds of people who contribute to a wide range of projects. Services like GitHub Sponsors are another vision for that but I don't think we've hit a good balance which doesn't result in a major project getting resources while a lot of smaller pieces languish. Umbrella groups like the Django Software Foundation are trying to help with that but I think that's still a work in progress.
Even though Microsoft deprecates versions of Windows, they often keep supporting the APIs used for insanely long periods of time. Open Source software doesn't really have the incentive to do this unless "forced" by leadership or a standards body (and even that isn't entirely well enforced, how deviated from Posix are we now).
Java may be similar to a cross between these - as old versions of the JDK continue to be supported and developed, but I assume there's money flowing somewhere to do so.
I work on a number of projects but they're all relatively small so even if the money was coming in it wouldn't be enough to hire someone / quit my job and that means that you're in a dynamic where what'd help most is contributing developer time but that's a lot harder than making a purchase for most organizations. If I offered paid support (or sold books or trinkets) it'd almost certainly bring in 1-2 orders of magnitude less than it'd need to transform the project structure.
That's basically the point I'm making. Paying $75 for printed documentation is easy to justify if your job involves Perl. If four developers work on Perl code, that's $300, which is nothing to the company and a lot better than the $0 they're getting now. Another example would be prioritizing bug fixes and new features.
The bigger problem to me is that maybe I could do that for Perl but it’d be even harder to say I need printed docs for every single CPAN module used on a project. Maybe if the core Perl team gets a ton of support they can spread some around but that’s tricky to match to the projects most in need.
- I got your code for free
- I set up Really Important Things using it
- I have contributed nothing to you, for years now
- I have also invested nothing in maintaining my Really Important Things (e.g. it is no one’s job at the company)
- How dare you change anything!!
You simply can't just decide to break something that hundreds of people have invested thousands of hours developing because you've now decided that you need some new fancy functionality, it's just a rude thing to do.
Even more importantly, legacy projects are the ABSOLUTE majority of Perl projects left alive, so breaking them would be even bigger screw up than the Perl 6 was.
BTW, no one says that language shouldn't be improved - that's a problem that can be very simply avoided with proper versioning. Instead of pushing for breaking Perl 5 backward compatibility just to avoid having to add a few pragmas to the top of their files, why not just help efforts on making Perl 7 a reality finally? Perl 5 will then then be free to focus on supporting the old projects and fixing bugs, while Perl 7 can add whatever they wish without worrying of old stuff...
But how long can someone reasonably expect newer releases to support legacy code? It doesn't make sense to hold back the development of the entire language just to support software that's 20+ years old.
>Instead of pushing for breaking Perl 5 backward compatibility just to avoid having to add a few pragmas to the top of their files
Because it make it harder for people to learn modern Perl when you have to just through hoops to enable features people expect in a modern language. It would make more sense to have pragmas to disable features for backwards compatibility. Or like the article mentions, just use an older Perl distribution. If your codebase is really that old there's really not much reason to use the latest version of Perl.
IMHO as long as majority of your users are on a certain version, you need at least to provide bug fixes for them.
> It would make more sense to have pragmas to disable features for backwards compatibility.
That would require people to edit all their old scripts to add these pragmas, which defeats the very idea of backwards compatibility.
If only people could agree on what "modern perl" is, then we could create a single pragma that would enable all the features expected by this modern perl in a single line. Or, we could just declare that modern perl to be the starting point of Perl 7, as it was planned. Problem however is that there's no even consensus on what are the features that should go into this modern version, and that blocks the language development far worst than not being able to implement breaking changes (and of course the fact that most of old maintainers have left the project and team is seriously understaffed)
And when that software breaks on an OS update (say CentOS 6 -> 8) is when often "virtualize that machine and keep running the old code" becomes the answer.
I had asked to write something in python at one job and my boss was like no, the call stack gets way too big and it uses too much memory, and you're installing an interpreter which may introduce security problems. Write it in Perl, it's included in the OS. I really wonder how correct he was on that performance stuff but it wasn't an unpleasant experience given my skill level in that language at the time. I think perl's major weak point is that it's kind of hard to read if you don't know it.
Anyway, for me, that was why Python “felt” slower than Perl.
There's a reason Linus does his hardest to avoid ever changing the user-facing kernel APIs (never break userspace). When you're a young language (Rust) you can get away with breaking API changes and your users will go along with it (often because they're asking for features they need to use the language) but at some point you cross the line where there's more code written than still to write.
I live in the enterprise software sector, and you don't know much problem it cause this. Because X is old and not updated, in must(? who knows but nobody dare to check) run in OLD OS, with OLD rmdbs, with OLD runtimes with OLD ssl libraries, etc, etc.
So, you come along with a neat solution to their problems, and you face the fact you must "downgrade" everything to compile/ship: Your lang, drivers, third-party deps, etc. And then you must hunt down the docs for all that!
THIS is the reason a lot of companies use old internet explorer/old windows/old linux. Because X not dare to break!
---
The silver line here is the advent of virtual machines and now docker. Moving forward, run in docker (or similar) is the ay to go for isolated that pesky dips that live in the old era.
But, sadly, docker don't run in that OS, because that pesky OLD deps need it!
[edit -- and yes, it's pre-1.0 code. Not trying to be sneaky, just trying to clarify that the backwards-compatibility guarantee only goes back to a reasonable point in time.]
I got a call last week to update a machine that's running VB 4 code from the mid-90s. It's a spot welder; the casting and transformers are from the 1940s, but the weld controller speaks RS-232 and is from the late 80s. I feel safe assuming the machine will still be in use long after I'm dead.
We did a quick update with the original source code to fix a glaring bug that a new operator happened across, but they would like to add a simple database integration feature. The interface simple enough that the update will be a nearly complete rewrite; we'll retain the .ini settings files and custom CSV file format. However, we will be choosing a platform that should last as long as the original. That platform will not be some new hot JS framework that's going to be marked end-of-life before the warranty is up.
Not everyone is on a 2-year treadmill!
For most other issues it's simply accepting the suboptimal choices made in the past.
I'm sympathetic to Perl, having gotten a huge amount of value from it over the years, but I'd bet that at its peak it was less than 10% of the number of lines of code written in COBOL since the latter had close to half a century head start and the fields where it was used made it a key component of the global financial network. That's generally harder to replace than the average Perl code and since there was a direct value visible from it companies also were less hesitant to hire people to throw bodies at maintenance.
An increasing risk of using Perl is that your dependencies may be rotting without you noticing it. And this may happen in multiple ways:
* Modules that use some arcane syntax that's being deprecated.
* Modules that link against libraries that are still being developed
* Web APIs that are still evolving.
Perl's great strength has always been CPAN, and with its decreasing popularity that's now becoming a weakness.
For instance, Amazon::S3 was last released in 2009. AWS::S3 was last released in 2019. Net::Amazon::S3 seems alive and well, but the "++ed by 6 PAUSE users" isn't very comforting.
I'm personally increasingly switching away from Perl, because I've been noticing the concerning amount of familiar modules whose last release was several years ago, which has bugs that went completely unacknowledged on the bug tracker for years, and the realization that there are big, complex modules that may be depending on some random person in Nebraska.
This is of course not a new issue, but it's particularly acute when an ecosystem is no longer "sexy" and people start moving on to greener pastures.
I would argue that the problem you see isn't so much with perl (although it's definitely less popular) but with the exponential dependency explosion with little verification that results from these sorts of systems.
At some point, something in the S3 API is going to change. Crypto modules are going to add some algorithms and deprecate others. Some big system library is going to release version 2.0. Ubuntu is going to stop the last LTS release where everything worked.
At my workplace we used to make very heavy use of Perl, and now that's gradually going away, because there's a fair amount of pretty big stuff that's either unmaintained, or at the very least concerning. The Wx module for instance has always been a bit of a pain in my experience and I don't know how much life it's got left. But I'm certainly not going to volunteer to maintain it if it ever breaks.
If Perl can only get the transformation piece where another language gets you to the last part then there is less reason to use Perl at all. That was Perl's bread and butter. It was the king of data transformation. It was even used (is used) to prototype data conversion from COBOL to xml. I've even seen it parsing COBOL code for keyword highlighting and hosting a website to view the results.
I could easily write that in SCALA today in a one stop shop, arguably faster.
Perl isn't dead but its not exactly alive. And let's face it, it isn't really being taught in schools anymore. It and PHP were when I was in college. Can any language fall to this fate? Sure, but if you stick with Java/Scala/Kotlin, Javascript/Typescript/Node and .Net/C#/F# you are pretty safe for a decade or two. Perl is just the weeds in the garden at this point.
Paws is actively developed too: https://metacpan.org/pod/Paws
And now you have a situation where you may be stuck - unable to update your program even if you want to until all dependencies are updated.
That probably depends on your bubble, but I've interacted with more code in Fortran and Cobol than in Perl. And Fortran and Cobol were "almost dead" long before I started my first job.
Dunno, I think glue languages like perl are inherently easier to replace than platform languages. And perl was only best at being a glue language for a very short period in 90s.
`perl -pe 's/foo/bar/g'`
Is there anything else present on most machines that offers as much regex-fu as perl?
“Perl still has its uses. For tiny projects (100 lines or fewer) that involve a lot of text pattern matching, I am still more likely to tinker up a Perl-regexp-based solution […] Actually, these are much like the things Perl did in its original role as a sort of combination awk/sed/grep/sh, before it had functions and direct access to the operating system API.”
— https://www.linuxjournal.com/article/3882
Personally, I write these kind of things in actual awk, sed, and shell script. If these are not sufficient, I skip Perl altogether and go directly to some modern higher-level language.
For perlre, probably not.
I've felt for a while that silent failure is a serious possibility when Linux distributions change bundled Perl versions with little or no discussion.
The medium-term answer for me is probably to learn Python well enough to port my code to it.
I'll note that Perl just went through a year or so of painful argument to rediscover that "Perl should stay Perl", so I'd be more confident in that.
Also, Python is at least as bad as Perl about breaking silently. If you care about maintaining a codebase over time, pick anything that has static types.
I’ve found Go to be a reasonable python replacement, though I haven’t found either python or go to be a reasonable perl replacement.
I don't have much invested in Python at the moment. I would be more aware of and concerned about Python issues if I had larger scripts written in it that I need to maintain.
I have used Perl 5 long enough to know that it is a mature language. I'm concerned about the integrity of CPAN and individual modules' abilities to interoperate with the versions of Linux that I deploy in production.
Perl prioritizes backwards compatibilty above all else so much so that it hides new language features behind either a version declaration `use v5.30;` or a feature declaration `use feature 'say'`
Code written on 5.8 (2002) will run perfectly fine on perl 5.34 (2021). The language and standard library have had a few deprecations but most of them were problematic or unused features and went through a long deprecation cycle where perl would emit warnings about the upcoming deprecation.
That's the core language though, there is nothing to be said about the consistency of CPAN modules just as with any other language's collection of third party libraries. Or with vendor packaging.
Old Perl programs can often run without any changes.
is you buy a new macbook today, the base system comes with a few hundred perl scripts and a few dozen python scripts. Please, dot believe me; just file|grep your path and check it yourselves.
This isn't criticism of those languages; it's a compliment! They've all hit maturity, in my opinion. That's a good thing. But I think their developer communities still sometimes don't act like that's the case, to their detriment.