What Happened to Perl 7? (2022)
blogs.perl.org
blogs.perl.org
That got a lot of attention four years ago. Larry Wall had approved changing the name of Perl 6 to Raku the year before. I don't think it's controversial at this point to say the Perl language will never see big changes. The only people still working on the language do so because they want to keep running the language they have now. That's fine, but as described in that article:
"The new features crowd has to deal with a longer boilerplate section in every program, and newbies wonder why they have to include so much just to create a program so people on StackOverflow won’t hector them over missing pragmas."
The principles of modern perl pretty much boil down to "use the new stuff and turn off the old stuff":
* use strict and warnings, those go without saying. 'autodie' is also pretty much de rigueur these days too.
* disable legacy things like bareword filehandles and indirect object syntax.
* enable unicode everywhere by default in strings and I/O layers
* use Moose, or at least a compatible subset like Moo or Type::Tiny. This is probably the biggest differentiator of modern perl, as Moose is a major addition to the OO system, basically a backport of the perl 6 object system.
I wouldn't say the evolution of the language via modules is any kind of "faction", it's very much the mainstream thought of perl and always has been. Perl was designed from nearly the start to be hackable from within itself.
Also quite a few hits on CPAN: https://metacpan.org/search?q=modern%3A%3Aperl (ima convert all my old production code to Acme::Thoroughly::Modern::Perl tonight!)
For stability, Perl defaults to an old stable behavior. Modern features are opt-in Perl::Modern is a handy way to select a version, sort of like Python's `from future import foo`
Searching for "perl" will lead you to https://www.perl.org/
Perl was the language best suited for text manipulation because of its early popularization of regular expressions. As such, it was excellent for a lot of tasks in « DevOps », even though that term wasn’t a thing then (everyone carried their own water).
I remember deploying a web forum that was coded in Perl once. I remember having to debug large Perl scripts and that was a nightmare. I remember a time when Python was a new odd thing and the long-bearded hacking elite joked about it.
But, all this will be lost in time, like tears in rain…
Just remember one thing: The mess you make with any language is yours, not the language’s.
#!/usr/bin/env perl
use v5.36; # Minimum version needed for this
use utf8;
use experimental qw/extra_paired_delimiters/;
my @arr = qw«foo bar baz»;
say $arr[1];It was awk, grep, sed, and lex that popularized regexpes before. Perl attempted to agressively replace awk and sh, even shipped or still ships the a2p.pl script to perform limited awk-to-Perl code conversion. What Perl brought were Perl-style regexpes with capture groups and back references, which are still not characterized in terms of formal language theory when good decision procedures were the entire point of subsetting lexical analyses from eg context-free languages or other more capable models, which is particularly odd considering Larry Wall is a linguist.
Agreed on Larry Wall understanding the difference between linguistics and computer science, languages for humans to use vs languages for computers to use.
Perl code that is syntactically correct only on Fridays: https://news.ycombinator.com/item?id=30359309
(Has to do with how subroutine prototypes change how the code parsed where the subroutine is called)
This thing that is different from other languages is having a static lexer and parser, versus having a fynamic one. In Perl you modify it indirectly, and in Lisp you can modify it directly.
The fact that this happens has nothing to do with Perl's syntax complexity, but everything to do with dynamism in parsing.
While awk is mostly used for text processing (and general data transforms, e.g. in the Linux kernel build system), it allows for writing arbitrary programs, e.g. first-person shooters: https://github.com/TheMozg/awk-raycaster
Thankfully, gawk has capture groups, which makes it a very useful tool, unlike the awk shipped with macOS by default.
The short version of it was that there was a bit of a power play by people who felt ignored and wanted a bigger part of what was felt to be an important development.
SawyerX goes into his a bit in a talk from 2023. https://www.youtube.com/watch?v=Q1H9yKf8BI0
This has resulted in a new (2024) code of conduct so that leadership can proceed without the previous sorts of verbal assaults effecting things again. https://news.perlfoundation.org/post/new-standaards-of-condu...
Definitely not a dead language. A mature and stable language, which won't surprise you.
1. you like perl and enjoy coding with it
2. you are good with perl so internet criticisms don't impact your decision
3. you don't care about contributions from other people
I guess some people just want to stick with what they know, and refuse to learn anything new.
That really depends on the use-case. If you need a batteries-included web framework, the top 3 that come to mind are Spring (Java), Django (Python) and Laravel (PHP).
And Laravel is a very good framework.
I really don't have much issue with modern PHP either, it gets the job done and unlike Perl is still very much evolving.
It also has various magic for router links that do partial refreshes and working with classic (non-json) forms and whatnot. I use none of those, I'm all about json and useFetch() instead, and Inertia's pretty good about getting out of your way when you don't need it. It lets you write as much or as little in SPA style as you want, it's more or less your favorite JS framework as a view layer directly without having to interpose another view as a middleman (the middleman is there, but it's all implicit: you add the @inertia directive inside your <div id="app">, and that's it)
(I can't personally vouch for the claim but it's the best explanation I've heard for how such a reviled language has survived this long.)
I have perl stuff written literally 20 years ago, that still works without issues, even on modern computers. If you need something to do the job and in ten years be called "legacy codebase", then do it in perl... because if you did it in python, you'd have to fix the 2.6->2.7 stuff, then 2.7->3.x stuff, and maybe even more than that. If you did what people here on HN like, so, use a 'language of the day', you'd have code written in ruby (now rust or go or whatever), which very few machines have installed by default now.
I, too, have 20 year old perl scripts that still run fine.
I randomly have to bang my head on my desk over bs with python and php incompatibilities between versions.
Pets perl
Over 25 years of Perl experience. Still writing new stuff daily, both for work and personal use.
My c code from 1996 requires rework. My C++ code from 2014 requires rework (I had to do this with others code as well to use a std capability). Python code rarely survives 3.6 -> 3.12 never mind 2.7 to 3.x. I worked at a company that had (very unwisely) written a massive part of its infrastructure in Py2.7, and was using it a decade past its expiration date.
Perl just works.
To say "This isn't going to work in 7 years", and be taken seriously would be a welcome reversion to current practices against good engineering.
For reference, PHP at the time was at version 4, Python was around 1.6, and noone had heard of Ruby.
Tech debt is going to happen regardless of the technologies you pick. But some technologies require more effort to keep up-to-date than others.
I’d also argue that keeping technologies up-to-date isn’t “tech debt”. It’s operational overhead. Tech dept is something else entirely.
Look at C. Each revision has added a bunch of minor fixes but has never addressed the core issues of the language that realistically require a rewrite (function pointer syntax, undefined behavior, null safety).
And there’s the fact that features bring in money and tech debt simply doesn’t. It’s still a business at the end of the day.
Major version changes are easy and rare.
The "interpreter-based threads" provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that makes them easy to misuse. Few people know how to use them correctly or will be able to provide help.
As a result, threaded Perl code or frameworks are extremely uncommon, even relative to Python.
On the other hand, the changes in my Ruby project have always been very manageable. Both the language and the ecosystem were reasonable those last years.
Once it grows a little bit more and starts requiring maintenance, I tend to rewrite it in a more maintenable language. Preferably a statically-typed language.
Of course, with a bit more verbosity, any such script could be written in Python. Perl was designed to fit this exact niche, so it has a bunch of small affordances for doing script munging eloquently (not to say elegantly!) but Python, or Ruby for that matter, can also get the job done. Most people who know either of those languages thoroughly would pick what they know: they'll do the job, and that spares learning another language, which is indeed a quirky one.
But for those who do know Perl, it remains a very good fit for a Practical Extraction and Reporting Language. For those who do a lot of 'scripting' tasks in the original sense, it's worth learning imho.
I would never consider perl for anything new in 2024. I still use awk very regularly.
I meant to say something more like "if you need to learn awk to do it, you may as well learn Perl instead". I figured from context that if you're "considering using awk", you don't know it, or you'd be "using awk". But no matter.
Perl can do everything Awk can, at least as well if not better. As fiddly, arbitrary, and limited, as Awk is, it's a lot less language, and that does come with advantages.
But I know from experience that you can learn the Awk subset of Perl as easily as you can learn Awk, and then you have a basis for extension to more tasks of a similar nature. If you want to see what I mean, there's a utility a2p[0] which translates Awk to Perl, this suffers slightly from machine translation, but it's a good demonstration that Perl can do everything Awk can in not just a trivial sense, but in the sense that it's designed to make Awk unnecessary.
So if you can get over whatever aesthetic hangup you have about Perlian line noise, you might discover you like it. Anyone using Awk "very regularly" is leaving a lot of potential on the table by refusing to learn Perl. Then again, sometimes it's best to stick with what you know.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Javascript is maybe 150% on average and C++ is maybe 200%.
If they're ever gonna do this P7 thing, it would be nice if there was a slight runtime improvement. There's some room available.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
I haven’t turned to it as my first choice in years, but it still has a place in my back pocket for if I ever need a quick and dirty text munging Swiss Army knife.
If you already know Perl, you already know if it’s right for you. If you don’t, you’re probably better off learning Ruby instead.
If I need more than a prototype, I reach out for Go. I have two major complains with Perl:
- it's more difficult to deploy (Go can be cross-compiled to a single binary which can then be scp(1)'d around, solid stdlib, no need to deal with dependencies on the remote, or modules split in multiple files);
- lack of static typing. You can get away with writing additional tests, but at the end of the day, that's just more work.
So despite being quite confortable with a fair subset of Perl, I (genuinely) can't think of a reason as to why I'd want to use it.
Now UNIX scripting that has no place being a bunch of sh scripts, definitely.
It's been a few years since I've known the following to necessarily be true but some examples that come to mind are Craigslist and BuzzFeed.
Now, from the outside looking in, I feel like Perl is stagnant.
Negative attention is better than no attention at all. With all their obsession with backwards compatibility, Perl should take a page from one of Philip K Dick's most bizarre novels, "Counter Clock World", where the Hobart Phase makes entropy runs in reverse, and regress Perl's version number each year. Then they'd be on Perl -20 by now!
https://en.wikipedia.org/wiki/Counter-Clock_World
>The novel describes a future in which time has started to move in reverse, resulting in the dead reviving in their own graves ("old-birth"), living their lives in reverse, and eventually returning to the womb where they split into an egg and a sperm during copulation between a recipient woman and a man.
[...]
>The Hobart Phase is the new order of life where people rise from the dead and are rejuvenated. Time reversal apparently began in 1986. Other than aging, Hobart Phase resurrection has changed nutritional and excretion processes and associated social taboos. People do not eat, but instead consume "Sogum" anally through a pipe, and later "plop" out food orally, which is done in private, due to its 'shameful' nature. As for smoking, cigarettes are no longer smoked, but the smoke instead blown back into them, making them grow back to normal size (this also clears and freshens the air). "Goodbye" and "hello" have reversed their order within standard greetings, and "food" is used as a drop-in replacement for the expletive "shit". It is stated that Mars colonists do not have the Hobart Phase on their world, and it is limited to Earth, and presumably its lunar colonies as well.
No food.
Holy food!
Day by day the world is getting foodier and foodier.
Over time I picked up php, python and node, but to this day my personal scripts are done in perl, and lots of command-line file wrangling starts with "perl -En".
I think two very early decisions doomed perl's ultimate future, and they were too ingrained in the language to ever change without losing compatibility. One is the shifting sigils, accessing @x with $x[3] instead of the logical @x[3]. The second is auto-flattening, where foo(@a) passes the contents of @a as separate arguments instead of @a as a single thing. Fixing these was so incompatible that the attempt turned into Perl6/Raku, which went way overboard in terms of design and failed to catch on. Meanwhile other dynamic languages converged on the better design of having containers be objects, and flattening done by an explicit operator.
I think perl has done a very decent job at turning into a legacy language, which was the right direction given the constraints. The maintainers have prioritized compatibility to a high level, while still slowly fixing whatever pain points they could, including finally adding function signatures (!).
$x[3] is perfectly logical when you think of the sigil as typing the value and not the variable. They're basically one-char cast/convert operators. Auto-flattening is less defensible. It was easier for me to intuit because @foo looks like a list splice in lisp and MOO code, so anywhere you see @foo in args, you can assume it's spliced in ... but then there's prototypes that change that. Yeah.
These just made Perl weird but they didn't reduce its power or expressivity. It was things like only having a single scalar type, or not even having named args without crazy shit like Devel::Declare that always had me looking for greener pastures.
Nowadays I spend most of my time writing PHP and TS. PHP is reasonably pleasant since the 8.x days, but I wish it had generics. And talk about having to crawl out from under a pile of bad legacy decisions...
> $x[3] is perfectly logical when you think of the sigil as typing the value and not the variable.
Unfortunately, that doesn't match the intuition of most programmers. It's more natural to think of the scalar variable as having the full name "$x" and the list variable having the full name "@x", since IIRC both can exist at the same time. Having "$x[3]" access the "@x" variable, when a "$x" variable already exists in the same place at the same time, is just plain confusing. Add to that the very similar looking "$x->[3]" syntax, which accesses the "$x" variable and not the "@x" variable (unless you made "$x" a reference to "@x"), and it becomes even less obvious.
Of course it took me learning XS and using Perl as an extension language (Lua was brand new and the Python GIL was a dealbreaker) to fully understand Perl lists, so yeah.
Python removes you from the system. Perl, like shell, keeps you in close contact with the system.
If a Linux/BSD distribution uses Perl in the base system, it is a plus for me. Unfortunately, most Linux distributions dropped Perl when they became bloated.
While python got dataclasses and type checking perl got... a few syntax upgrades many of which never left experimental and ended up being deprecated. The smartmatch implementation was beyond terrible, and implicit arrayref arguments should have never made it past the design phase. And still no native object/class system. Still no working exception handling!
I don't know if the perl runners are incompetent, badly organised or just hamstrung trying to guarantee backwards compat for all the legacy code. But as a Perl user it has been very frustrating to watch.
As is tradition this was the subject of a very engaging talk at the most recent TPRC: https://www.youtube.com/watch?v=0x9LD8oOmv0
Useful talk deals in benefits and tradeoffs (as the linked article demonstrates in spades). Useless talk deals unsupported “should”s.
* the module system literally just runs a script, so it can do -anything-. As a result there are 3 or 4 competing install systems all with their own cruft, some defined entirely using Perl as config, some using YAML. You need to have all of them installed.
* Of these, Module::Build is a common one written by someone who completely overengineered it, and it installs hundreds of dependencies, even though all it really does is just copy some files.
* Install scripts can do stuff like ask you interactive questions that prevent automated installation, which is a constant hindrance when packaging Perl modules e.g. to RPM
* Perl leaves literally everything up to external modules, including exporting functions or even defining module dependencies (e.g. 'use base', 'use autoclean', 'use Exporter' ...) and often the module config is written entirely in Perl rather than YAML or JSON file, so trying to do anything clever (like add IDE/language server support) is an absolute nightmare.
* The client to install new modules initially asks about 20 questions and does a slow mirror test, making it difficult to use in automated settings. Luckily someone wrote cpanminus which literally does exactly what you want - installs the damn package.
If what you really like though is the charge you get out of just saying "this is dumb" while indulging the privilege to not even notice that you did a repeat performance of unsupported shoulds vs worthwhile tradeoffs, though, well, maybe you should examine that.
It isn't hamstrung; it's a language that has stayed itself. If you want to run a perl script you just use your system perl (and it doesn't matter how old or new the OS is). If you want to run a python script you have to set up a container then use a package manager to setup an entire dedicated python and libs just for that script. Python may have acquired many nice features and refactorings but it stopped being a dependable shell language.
It traded run time complexity for write time ease; it's that way with all popular languages eventually. Not being popular after the Perl 6/Raku debacle is the best thing that could've happened.
You mean camel? PHP is the elephant. ;-)
https://en.m.wikipedia.org/wiki/PHP
See the Mascot section.
Postgres is the elephant.
>A group of blind men heard that a strange animal, called an elephant, had been brought to the town, but none of them were aware of its shape and form. Out of curiosity, they said: "We must inspect and know it by touch, of which we are capable". So, they sought it out, and when they found it they groped about it. The first person, whose hand landed on the trunk, said, "This being is like a thick snake". For another one whose hand reached its ear, it seemed like a kind of fan. As for another person, whose hand was upon its leg, said, the elephant is a pillar like a tree-trunk. The blind man who placed his hand upon its side said the elephant, "is a wall". Another who felt its tail, described it as a rope. The last felt its tusk, stating the elephant is that which is hard, smooth and like a spear.
Then 2.7 came out.. and 3.0...
This does kind of remind me of the Python 2/3 and Java 8 vs newer versions situation - where both the older and more stable version is maintained, but most of the development effort moves over to the new version. The good news is that for a while you get a really stable platform, but the bad news is that eventually it'll get deprecated and you won't find many new libraries and such developed for the old version anymore.
While something like Perl and Pascal (especially with Lazarus; a really good combo for building GUI apps and still an okay language, except the ecosystem is limited) are unlikely to disappear anytime soon per se, the flip side is that some of the existing libraries and frameworks might fall out of being maintained, or even entire projects be abandoned, like BackupPC, for example, with nobody really stepping up to keep them alive: https://backuppc.github.io/backuppc/
There's https://metacpan.org/dist/perl/view/pod/perlclass.pod, which (granted) is experimental, but it's actively being worked on.
> Still no working exception handling!
There's https://metacpan.org/dist/perl/view/pod/perlsyn.pod#Try-Catc... which is now (5.40) no longer an experiment, _aside from_ the use of `finally`, which warns.
> trying to guarantee backwards compat for all the legacy code
Not "all", as there are indeed deprecations added over time, but _most_. I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly.
"Cool kids" languages like Python and Rust really put in the mind of people that a program written two weeks ago must be upgraded to run on the new version of the compiler or interpretor. Meanwhile there always have been languages like C# or C where a codebase from 15 years ago will compile and run just fine.
I am not aware of anything in current Python 3, that has broken backward compatibility to an earlier Python 3.
Some dependencies are implemented in ways, that will require you to use newer Python versions. Often those are packages, which are glue for lower level libraries. Like tensorflow.
Perhaps I am describing the same thing as in JS ecosystem. But for some reason neither have I migrated to another way of defining my API routes in Django lately, nor have I had any need to in the last couple of years. I guess in the JS world there is just so much more half-backed stuff that gets hyped to no end, and this job guarantee is celebrated as "quick evolution".
Here's a list of things that were removed from Python in 3.12, most of were deprecated after the 3.0 release.
You can fix this by using -Wall -Weverything -Werror to ensure in 15 years time, the code won't compile any more.
I’d actually go even further and say that the only appropriate time to use -Werror is when running tests for code that hasn’t been merged yet… once it’s “released” you don’t want to use -Werror any more.
Ditto automatically running unit tests/etc too. (Perl is actually a major offender here… last time I used Perl, installing a module from CPAN would run its unit tests by default. Why do I, some random person installing this module, care if the tests pass now? The tests should have been run prior to this being published! I have horrible memories of the DBD::MySQL package failing to install because it ran tests that assumed localhost was running a MySQL server with anonymous auth enabled and the whole module failed to install if that wasn’t the case.)
Because running those tests in your environment ensures that... that module can run in your environment.
By way of example, if a module requires a specific library installed to actually run, running its tests will ensure you catch the problem, and install it, so it can then actually run. Else you'd only find out at runtime that something's missing.
Note also that not all tests are the same, and (unfortunately!) not all modules' tests are the same, either: there's tests that ensure the module works "generally", and there's some author/development tests that on a _properly written_ module are only ran by the author/developer, and skip running when the modules are instead installed by mere users, for whom instead the "standard" "will this module work in this environment?" tests are the only one that get ran.
> I have horrible memories of the DBD::MySQL package failing to install because it ran tests that assumed localhost was running a MySQL server
I believe that got fixed, IIRC, as I've had no trouble installing that module (and running its tests at install time, natch). I said "fixed" as that seems like the sort of test that makes sense for the module's authors/developers to run, and not mere users of it.
That wouldn't have changed with Perl 7, because Perl 5 would have been put into "long term maintenance mode". In fact, backward compatibility would have been even stronger, because all the changes would have gone into Perl 7.
I'm personally of the idea that enough backwards compatibility _should_ be preserved, but not _so_ much as to inhibit new/better syntax constructs and the like.
But honestly it's the sort of thing that is more like "I'll know it when I see it" more than anything.
Re "long term maintenance mode", there's the not so small matter of how many people can, in fact, actually develop perl. The codebase is large and full of many traps. It's a difficult, but not impossible, codebase to contribute to.
My sincere hope is that enough things will get out of "experimental", including quite a bit more of the "class" feature, for the end result to be enough to be called "7" and we'll go from there.
Basically... mostly a marketing thing, as today's 5.40 is way, way different (and better in so many respects) than 5.8 or 5.20 or even 5.32... but the (minor) version number doesn't show that.
A "perl 7" would.
Yeah, and that was one of the main reasons cited when they announced Perl 6, back in 2000. 24 years have passed and it's still an issue.
Python's dataclasses are just a simplified copy of the existing attrs pypi library. The implementation of them is a mess. I use Python every day and have plenty of nice things to say about it, but dataclasses and python types would be close to the top of the list of things I think are done most poorly in Python.
For ML stuff there’s no way around using Python (pytorch, TensorFlow, etc. etc.). While I appreciate that ML researchers make their models available to run locally, if you’ve ever run LLMs or SD, it’s very clear the focus is on getting models out of the door before others. But man is it a hot mess: every model needs its own Python version/installation from various sources (OS provided, github, package repos, python.org downloads, etc.), the code bases being rife with dozens of module and environment managers and other meta crap that obviously doesn’t cut it, Python devs using a dynamic language but then want types/annotations badly, etc etc. Sorry but from a SW engineering PoV, Python is pure and utter trash (it started life as a better BASIC for learning after all). I’m particularly puzzled by developers choosing/advocating Python for system administration and as shell replacement who now have to ship a locked–down Python version and package repo such as RedHat and Apple.
Perl 5 code, by virtue of being frozen for over ten years in anticipation of what’s now called Raku, has a slightly better chance to run OOTB. But there’s no guarantee: recently came accross 2000ish Perl code using jcode (lib for Shift-JIS and other CJK two byte encoding) that I couldn’t run because jcode uses hashing sigills that were removed from Perl since or something.
Both of these describe a write-only language, and Perl doesn't disappoint. Yes, I have seen well readable Perl code, it exists. But the language doesn't nudge you that way.
I read that as "Perl has remain stable for over 20 years".
The perception that it has stagnated appears to be poor marketing for the new features. For example, this article from 2022-09-08:
https://stackoverflow.blog/2022/09/08/this-is-not-your-grand...
https://news.ycombinator.com/item?id=32767218
Which starts off with "If you were to search the internet for recent articles about Perl, you might well be led to believe that the language hasn't changed in the last twenty years."
My guess is that since older versions of Perl are mostly adequate and code targetting them continued to work year after year, there was little motivation to check out new features of Perl.
Luckily Perl is so powerful that third party modules can do pretty much anything. There have been modules out for 10+ years that hack the parser and added function signatures (with types!) to the language before Perl did. Unfornaturely they're buggy and if you make a syntax error the output makes no sense :P