Should Perl die gracefully?(phoenixtrap.com)
phoenixtrap.com
Should Perl die gracefully?
https://phoenixtrap.com/2021/06/01/should-perl-die-gracefully/
74 comments
Well, unless Larry Wall suddenly decides to make those breaking changes this really doesn't apply to big community driven projects like Perl - they don't belong to any one group of developers, so neither group can decide to break them as they wish.
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...
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...
>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.
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.
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.
> But how long can someone reasonably expect newer releases to support legacy code?
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)
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)
An example is the Python 2/3 debacle - it took forever and still isn't complete (and now there are documents on how to install Python 2 to run older software).
[deleted]
This might seem like a stretch. But could hiring people to work on Really Important Things be interpreted as a form of support?
"Really Important Things" are usually business-internal software (for example, there are likely thousands upon thousands of perl scripts mangling data for company systems, where the original developer is long gone but they continue to work). Developer time spent on that doesn't really benefit the community as a whole beyond a blog post here and there about some aspect of how to set it up.
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.
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.
Like a blockchain.
I have a few critical system integration scripts written in Perl.
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'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.
Curious what makes you think Python will be less susceptible to this, after the whole 2to3 debacle?
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.
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.
This. Perl at least attempts to maintain backwards compatibility. Python libraries and the interpreter actively break old code all the time.
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.
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 know. I felt that Python 3 was an attempt to route around problems in Python 2 that couldn't be easily fixed.
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.
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.
Silent failure based on running your code in newer version of perl5 is very unlikely to happen.
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.
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.
For a Perl-to-Python journey, the first thing you should probably read is this:
https://www.linuxjournal.com/article/3882
https://www.linuxjournal.com/article/3882
Perl _has_ died gracefully.
Hell, not even Fortran and Cobol are really dead, and Perl is way more popular still. You still have millions of perl scripts running daily, many of them doing some really critical stuff. It's not mainstream language anymore as it used to be once upon the time, but falling from spotlights isn't the same as dying (which Cobol demonstrates successfully again and again every few decades).
> Hell, not even Fortran and Cobol are really dead, and Perl is way more popular still.
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.
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.
The key is it's being used but the scripts are more and more not maintained - and if you want users to not stay on outdated versions you have to consider that. Many security patches will be avoided if upgrading breaks stuff. Like Raymond Chen says - if upgrading Windows breaks your software, you will blame Microsoft even if the software is where the error is.
Both scripts and perl itself are being maintained. It's definitely not dead and pretty unlikely to die any time soon.
The big issue is with CPAN.
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.
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.
Absolutely but that's a serious problem with any language that does automatic dependency handling this way.
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.
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.
It's a problem regardless of dependency handling though.
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.
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.
In today's topography, these dependencies drive the use case more times than not. Something like 'As a clerical manager I want IT to take an old nightly file (proprietary fmt) and transform it to CSV and put it onto our S3 drive so that we can get the data into our EDW staging area.'
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.
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.
This is a very good point - many perl scripts are simple text-processing programs that don't depend on much from CPAN - but others are large projects that pull in multiple dependencies, and as those begin to break so do the programs.
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.
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.
>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.
Paws is actively developed too: https://metacpan.org/pod/Paws
Paws is actively developed too: https://metacpan.org/pod/Paws
> not even Fortran and Cobol are really dead, and Perl is way more popular still
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.
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.
Exactly my point, Cobol was considered "old" even in times before Perl became popular. I remember when I was doing C in early 90s, Cobol was something "only old guys use". And nevertheless it's still alive and kicking in its niches today. So is Perl, just in different places.
I feel Cobol was more used in "main business critical applications" and perl was found much more in "wedge this here to keep the first working" but I don't have much to back that up beyond anecdotal evidence.
> So is Perl, just in different places.
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.
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.
Ok, then it hasn't died gracefully, but sound like it's on its way to join these other "undead languages" where almost no new code is being developed and it's getting harder and harder to find competent developers?
As someone who has written a fair bit of Perl, lots of us have moved to other languages like Java/Scala/Python etc. I could still write Perl if I needed to but having dealt with maintaining a "large" system written in Perl and having used aforementioned "proper" object oriented languages since then, I would restrict using Perl to simple/small scripts, given that I had no other choice.
All the competent developers were driven away by its maintainers. Who themselves have no idea how to implement the spec'd features missing. So, yes. It's dead. There's a lot of insignificant noise about perl 7, drama and the new object system, but if you look at the heads and devs it's getting worse and worse.
I’m pretty sure autovivification will keep it humming along indefinitely.
I still create scripts that include bits like
`perl -pe 's/foo/bar/g'`
Is there anything else present on most machines that offers as much regex-fu as perl?
`perl -pe 's/foo/bar/g'`
Is there anything else present on most machines that offers as much regex-fu as perl?
To quote Eric Raymond:
“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.
“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.
[deleted]
For examples such as that, sed and awk will do you fine for POSIX / GNU regex.
For perlre, probably not.
For perlre, probably not.
[deleted]
Was it graceful? TMTOWDI, after all.
[deleted]
I still find perl to be pretty sweet for handling old data formats. Need to extract something out of an old foxpro DBF file? Perl has some great tools for that. Have a collection of excel files with the formats ~MIXED TOGETHER~ between xlsx and xls, and don't want to deal with using two seperate libraries in python or whatever? Perl is pretty sweet for that, handles both formats transparently -- I think they even have it as the example on their front page.
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.
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.
Having written lots of Perl and Python, Perl just _felt_ fast (I don't have benchmarks to back this up). Also agree on the included in OS point (when I started coding in Perl, it came pre-installed on Sun Solaris; I do remember seeing some old version of Python too but by then we already had written a bunch of Perl).
Global variables in python are (used to be?) about 10x slower than variables in a scope. I gave up on python for other reasons (breaking changes every few months) before someone pointed that out to me.
Anyway, for me, that was why Python “felt” slower than Perl.
Anyway, for me, that was why Python “felt” slower than Perl.
If your users are saying "stop messing with the language, we're no longer developing in it" you may want to consider why.
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.
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 think a language must break moving forward. The more something is afraid of change, the more it stay like that AND DRAG EVERYTHING ELSE.
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!
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!
Sort of unrelated, but Rust doesn't make breaking changes. The language is fully backwards compatible.
I have some ten-year-old Rust code that would disagree with you. :)
[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.]
[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.]
Rust 1.0 came out 6 years ago. There’s no need to sow confusion by referring to pre-1.0 code here.
That's a major version, yes, but not necessarily sowing confusion. Users have needs that often last longer than 6 years.
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!
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!
The point of it being pre-1.0 is not that it was a different major version, but that it had not reached the first major version. pre-1.0 versions were explicitly ALPHA software subject to constant change as indicated in release announcements e.g. https://mail.mozilla.org/pipermail/rust-dev/2014-October/011...
There's a big difference between maintaining backwards compatibility with VB4 and VB pre-1.0.
That's some impressively old rust code — from long before the initial release of the language!
To be fair, pre-1.0 Rust was already heavily hyped and available. It's not hard to find plenty of projects from that time.
Is this due to features being available as macros and such?
For syntax level changes, "editions" allow libraries to opt into the new language version while keeping compatibility with old libraries.
For most other issues it's simply accepting the suboptimal choices made in the past.
For most other issues it's simply accepting the suboptimal choices made in the past.
Posts like this are really hitting a key social challenge for open source in general: a large fraction of complaints like this come from companies which derive commercial value from projects like Perl but often do not contribute to maintenance. There's an easy criticism that these companies are basically freeloading, and there's definitely some truth to that but I think it also touches on the difficulties of doing so: most companies aren't set up to make small donations efficiently and it's hard to say which fraction of the business value would be allocated between Perl and the hundreds of CPAN modules they're likely using.
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.
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.
I've made the point repeatedly over the years that open source projects have to sell something if they want financial support. In the case of Perl, maybe it's a particular implementation that comes with printed documentation. "Download the stuff you want to use and then make a donation of arbitrary size if you feel like it" isn't going to work. The RHEL model won't work for most projects, because Red Hat has traditionally sold support services. Slackware would be a better example. You used to be able to buy CDs with the new release if you wanted to support the project.
One of the key things RedHat sells is "your code doesn't need to change for X years" - but a side effect of this is you suddenly have a BUNCH of changes that need to be made every X years as new distributions come out.
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.
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 think that's true but it's hard to do: I can't go to purchasing and say “we should donate $50,000 on these 139 projects”, and it will definitely raise questions if you're paying for something vague or not clearly linked to a business value but selling support puts the project in the critical path for actually having to deliver it.
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.
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.
> I can't go to purchasing and say “we should donate $50,000 on these 139 projects”, and it will definitely raise questions if you're paying for something vague or not clearly linked to a business value but selling support puts the project in the critical path for actually having to deliver it.
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.
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 problem I’ve seen is that it often goes more like “do we really need 4 copies, can’t they share?”, “isn’t the 2020 version still enough for 2021?”, or “isn’t that all online anyway?”, and even if it works $300 after overhead isn’t much developer time. Trying to do it sideways like this can be frustrating at large companies because the same place which will pay an enterprise vendor 7 figures to have the privilege of training the vendor’s support contractors will nickel and dime you for less familiar arrangements.
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.
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.
There's always ActiveState Perl: https://www.activestate.com/products/perl/
The last active state perl maintainer was fired years ago.
That would make it inActiveState Perl...
This is untrue.
I use it for regex on the WSL shell. Another win for M$!
should Python die, also?
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.
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.
Personally I would say all the dynamic scripting languages, while they shouldn't "die", should stop focusing on adding new features and focus on the other things that will enhance the value of the language as it exists.
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.
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.
The Perl developers have actually done an excellent job of maintaining compatibility.
Old Perl programs can often run without any changes.
Old Perl programs can often run without any changes.
- 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!!