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

Golang declared a perfect backwards compatibility guarantee way back when version 1 was released. So in this regard, Perl isn't unique.

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.

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.

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.

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)

> 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.

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)

Perhaps, but code that inadvertently depends on the Hash implementation returning keys in a particular order is arguably incorrect.

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

In fairness to Perl, that's a good reason not to consider it a breaking change.

perl 6/raku was a redesign. as far as i remember, upgradeability from perl 5 without code changes was never the goal.

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.

Agreed. Probably why they renamed it. I think everybody probably wishes they'd taken a new name from the start.

> It's too bad Raku didn't have a different name from the start.

We thought that it would take a year or two, not decades.

Also, the intent was to have a Perl 5 compatibility mode.

Looks like the last time I tried out Perl 6 was almost 10 years ago. Even wrote a few blog posts about it before giving up on it again. Might be time to take another look.

There is a Perl 5 compatibility mode: it's called Inline::Perl5.

Maybe not the one that was originally planned. But that was only a real possibility if Perl 5 would be able to get rid of its XS addiction.

Ask yourself: how many of the up river Perl modules are Perl only?

Isn't that the definition of a breaking change?

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.

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.