5 ms·

Yes, it's still well-maintained and highly backwards-compatible, avoiding breaking changes between releases.

walterbell 1y ago
We need an ROI metric to quantify the backward compatibility and low churn of Perl relative to languages like Python, Ruby, golang.
- lordofgibbons 1y ago
  Golang declared a perfect backwards compatibility guarantee way back when version 1 was released. So in this regard, Perl isn't unique.
  - naikrovek 1y ago
    well, Go has broken that backwards compatibility when it was deemed important enough to break things. So it's not "perfect" and I imagine Perl's isn't either.
    - drysart 1y ago
      Perl as a language is pretty mature and rarely sees breaking changes (and what breaking changes exist are in corners of the language that are extremely esoteric even for Perl). You can take a Perl script written 25 years ago and it'll still run just fine. New language features and things that might alter existing behavior are usually locked behind a version declaration opt-in at the top of your script. You need to do something similar to `use v5.39;` to unlock new behaviors from that version of Perl -- which may contain breaking changes but those are also generally backward compatible too. But that's for the base language and standard library. Individual third-party packages may vary in their backward compatibility.
      - dcassett 1y ago
        I remember a breaking change that was not esoteric: "keys %hash" started producing a different result each time the script was run. It required replacing the construct with "sort keys %hash" to get reproducible results.
        librasteve 1y ago
        Perhaps, but code that inadvertently depends on the Hash implementation returning keys in a particular order is arguably incorrect.
        jcynix 1y ago
        I can't remember a time where "keys %hash" returned the keys in a defined order. And I've been using Perl for over 30 years now. I've just consulted my first issue of "Programming Perl" (printed in 1990l and it says: keys (assoc ARRAY) this function returns a normal array consisting of all the keys of the named associative array. The keys are returned in an apparently random order, but it is the same order as either the values() or each() function produces (given that the associative array has not been modified)
        dcassett 1y ago
        Agreed, but prior to the change the "apparently random" as described in the documentation was similar to using random(fixed_seed), rather than the new behavior of random(system_time), which made the output of the script non-reproducible given the same inputs. The change to Perl's behavior was made for security reasons. (Edited for clarity)
        ether_at_cpan 1y ago
        > I can't remember a time where "keys %hash" returned the keys in a defined order. It was never a _defined_ order, but before version 5.17.6 (November 2012), each hash returned its list of keys and values in a _consistent_ order between runtimes, so some code ended up getting written that depended on this ordering (say in a unit test, or a list that would get assigned into a database). The change was to make the ordering random/inconsistent/unpredictable every time the list was fetched, which as I recall did break some number of tests in CPAN modules and required new releases.
martinflack 1y ago
And the last release was three weeks ago! Perl 5.42.0 was released July 3, 2025.
SoftTalker 1y ago
> avoiding breaking changes Perl 6? It was so breaking they don't even call it Perl anymore.
- kstrauser 1y ago
  In fairness to Perl, that's a good reason not to consider it a breaking change.
- em-bee 1y ago
  perl 6/raku was a redesign. as far as i remember, upgradeability from perl 5 without code changes was never the goal.
  - SoftTalker 1y ago
    Isn't that the definition of a breaking change?
    - em-bee 1y ago
      yeah, in the same sense that D is a breaking change for C, or wayland for X11. the point is that as far as i know it was never intended that existing perl 5 code would be rewritten. unlike the python 2 to 3 change where the intention was that people would convert using 2to3 and later using compatibility modules that allowed writing code that works with both. python 2 development stopped after 12 years, much later than they expected.
    - 0xbadcafebee 1y ago
      If Ford makes a 4-door passenger car, and then comes out with a 2-door sports car, and keeps producing both cars, that's not a breaking change. It's just a new car. Perl 5 is still supported, Perl 6 (Raku) continues independently.
  - aaronbaugher 1y ago
    It's unfortunate that that wasn't clear to people who weren't closely involved with Perl at the time. So many people got the impression that Perl 5 was outdated as soon as 6 was in development, so they thought they had to move on from it. It's too bad Raku didn't have a different name from the start.

We need an ROI metric to quantify the backward compatibility and low churn of Perl relative to languages like Python, Ruby, golang.

lordofgibbons 1y ago
Golang declared a perfect backwards compatibility guarantee way back when version 1 was released. So in this regard, Perl isn't unique.
- naikrovek 1y ago
  well, Go has broken that backwards compatibility when it was deemed important enough to break things. So it's not "perfect" and I imagine Perl's isn't either.
  - drysart 1y ago
    Perl as a language is pretty mature and rarely sees breaking changes (and what breaking changes exist are in corners of the language that are extremely esoteric even for Perl). You can take a Perl script written 25 years ago and it'll still run just fine. New language features and things that might alter existing behavior are usually locked behind a version declaration opt-in at the top of your script. You need to do something similar to `use v5.39;` to unlock new behaviors from that version of Perl -- which may contain breaking changes but those are also generally backward compatible too. But that's for the base language and standard library. Individual third-party packages may vary in their backward compatibility.
    - dcassett 1y ago
      I remember a breaking change that was not esoteric: "keys %hash" started producing a different result each time the script was run. It required replacing the construct with "sort keys %hash" to get reproducible results.
      - librasteve 1y ago
        Perhaps, but code that inadvertently depends on the Hash implementation returning keys in a particular order is arguably incorrect.
      - jcynix 1y ago
        I can't remember a time where "keys %hash" returned the keys in a defined order. And I've been using Perl for over 30 years now. I've just consulted my first issue of "Programming Perl" (printed in 1990l and it says: keys (assoc ARRAY) this function returns a normal array consisting of all the keys of the named associative array. The keys are returned in an apparently random order, but it is the same order as either the values() or each() function produces (given that the associative array has not been modified)
        dcassett 1y ago
        Agreed, but prior to the change the "apparently random" as described in the documentation was similar to using random(fixed_seed), rather than the new behavior of random(system_time), which made the output of the script non-reproducible given the same inputs. The change to Perl's behavior was made for security reasons. (Edited for clarity)
        ether_at_cpan 1y ago
        > I can't remember a time where "keys %hash" returned the keys in a defined order. It was never a _defined_ order, but before version 5.17.6 (November 2012), each hash returned its list of keys and values in a _consistent_ order between runtimes, so some code ended up getting written that depended on this ordering (say in a unit test, or a list that would get assigned into a database). The change was to make the ordering random/inconsistent/unpredictable every time the list was fetched, which as I recall did break some number of tests in CPAN modules and required new releases.

martinflack 1y ago

And the last release was three weeks ago! Perl 5.42.0 was released July 3, 2025.

SoftTalker 1y ago

> avoiding breaking changes Perl 6? It was so breaking they don't even call it Perl anymore.

kstrauser 1y ago
In fairness to Perl, that's a good reason not to consider it a breaking change.
em-bee 1y ago
perl 6/raku was a redesign. as far as i remember, upgradeability from perl 5 without code changes was never the goal.
- SoftTalker 1y ago
  Isn't that the definition of a breaking change?
  - em-bee 1y ago
    yeah, in the same sense that D is a breaking change for C, or wayland for X11. the point is that as far as i know it was never intended that existing perl 5 code would be rewritten. unlike the python 2 to 3 change where the intention was that people would convert using 2to3 and later using compatibility modules that allowed writing code that works with both. python 2 development stopped after 12 years, much later than they expected.
  - 0xbadcafebee 1y ago
    If Ford makes a 4-door passenger car, and then comes out with a 2-door sports car, and keeps producing both cars, that's not a breaking change. It's just a new car. Perl 5 is still supported, Perl 6 (Raku) continues independently.
- aaronbaugher 1y ago
  It's unfortunate that that wasn't clear to people who weren't closely involved with Perl at the time. So many people got the impression that Perl 5 was outdated as soon as 6 was in development, so they thought they had to move on from it. It's too bad Raku didn't have a different name from the start.