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."
That big boilerplate section can be rolled into a single pragma like Modern::Perl, and it's trivial to write such pragmas yourself using Import::into. The difficulties with the boilerplate are overrated, it's the incredibly loose type system that resists any attempts at static typing, and can't even differentiate numbers and strings except by having different operators for the two. Sigil soup still turns people off too, me included even after doing perl off and on for 20 years.
What on earth is modern Perl? I tried asking my search engine. I got nothing that showed me examples of what the code looks like. Is there really a popular faction in the Perl community that's evolving the language in a different direction using modules?
http://modernperlbooks.com/books/modern_perl_2016/index.html ... seriously tho, if your search engine didn't at least link "modern perl" to somewhere in that site, something's very wrong with it. (edit: I see what you mean, it's thin on worked examples. I'd say browse around cpan for new uploads, most new perl code these days uses modern idioms)
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.
Moderl Perl is the recent versions of perl, like modern Java is the recent versions of Java. But Perl is more flexible providing forward compatibility.
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`
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.
> Perl was the language best suited for text manipulation because of its early popularization of regular expressions.
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.
As a linguist, Larry was also acutely aware of the difference between prescriptive rules of grammar vs how language is actually spoken by real people, and in terms of informing Perl he always came down firmly on the side of the latter. And now perl is the gold standard for "regexes" even if they don't encode regular grammars anymore.
Agreed on Larry Wall understanding the difference between linguistics and computer science, languages for humans to use vs languages for computers to use.
I think his linguistics background helped him push the boundaries of what people expected from computer programming languages rather; being able to break out of the PL design mindset is part of what made Perl groundbreaking. If I recall correctly, the syntax and semantics of Perl are intertwined to the point that parsing Perl without also evaluating is provably undecidable. From a purely academic standpoint, that sounds like a nightmare, but it's hard to argue that Perl didn't have a significant impact. Many people can learn all the rules and conventional wisdom in a field, but being able to understand the underlying principles well enough to ignore some of them and produce something of value is much more rare.
> If I recall correctly, the syntax and semantics of Perl are intertwined to the point that parsing Perl without also evaluating is provably undecidable.
Not that big of a deal. Lisp has a drastically simpler syntax, but can behave is the same way.
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.
That's hilarious, somehow I had never seen that one before! I love how it immediately makes it much more visceral how wild things can get without needing to get into the weeds of how programming languages work.
Regexes without capture groups are about 90% less useful. If you do not include backrefrences, you still have a regular language, and a matcher can have a guaranteed reasonable run time.
Thankfully, gawk has capture groups, which makes it a very useful tool, unlike the awk shipped with macOS by default.
It’s hard to call awk, grep, sed, lex, programming languages, don’t you think?
It would be even harder to say they popularized regular expressions, considering their very very limited reach.
I agree with the rest.
Awk is a bona fide programming language. It makes line-oriented processing extra easy, but so do Perl and Ruby.
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
awk is definitely a programming language, and I've seen people abuse sed in unsettling ways, but yeah, grep sure isn't. lex at least generates C source code but isn't itself a programming language. But they all definitely made regular expressions a normal programming tool well before perl existed.
#!/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];
This article predates the resignation of SawyerX (due to a lot of the abuse and misery heaped on him), who was the Perl release manager (aka "Pumpking") that was in charge of Perl 7.
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.
Are there any circumstances where starting a new project with perl makes sense today? I am curious because I only encountered perl in legacy codebases.
Perl as a scripting language remains undefeated. As in, let's say you are considering Awk for some task. It's probably worth learning how to do that task in Perl instead. The same applies to many classic uses of bash scripts: today, the biggest reason to choose to write a shell script is to provide some service which will be universally available on plausible platforms, and Perl isn't that ubiquitous any longer. But for most of what shell scripting was intended for, Perl is a more powerful and less, let's say idiosyncratic, choice.
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.
Except, I know how to slice and dice text with awk, and can do it without leaning on ChatGPT or studying language documentation. Never made the leap to perl, the few times I tried I was put off because to a newbie the language looks like gibberish.
I would never consider perl for anything new in 2024. I still use awk very regularly.
> Except, I know how to slice and dice text with awk
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.
I've started to write my one off scripts with an AI prompt, and Python as a simpler and more verbose language with a bigger training corpus is easier for that. Or I ask for a bash script! Still writing my one liners in Perl but they're getting shorter and shorter.
Ok, but if you’re comfortable using it, Perl is really fun, pleasant, and easy to quickly express ideas in. One of its conscious design decisions is to be flexible enough to rapidly bang out some quick hack you’ll never look at again in absolute incomprehensible gibberish shorthand, or to use in a very methodical, disciplined, and structured way — so if you write something unmaintainable, that’s because you chose to.
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.
I've used Perl extensively for a few years professionally. For prototyping, say text-processing stuff, I reach out for awk/sh, which are usually sufficient.
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.
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.
In a previous company, I had to support TypeScript code that wouldn't even survive 12 months without something breaking upstream. Granted there were a lot of other things that company did wrong...a hell of a lot! But it's insane how little importance people seem to place on code longevity these days.
I’m not on about fixing tech debt. That’s a completely different problem to picking boring technologies that don’t need constant ongoing maintenance just to keep running.
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.
In my experience, tech debt often requires too great an investment to fix so the team just ends up bikeshedding to show progress but without real benefits.
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.
Right. I started a perl codebase in 1999, which has slowly evolved and is still one of my main projects to this day. The language has slowly improved, there are decent libraries for everything you might want to do, and I've basically never had to rework or throw away my code because of incompatible changes in the language.
For reference, PHP at the time was at version 4, Python was around 1.6, and noone had heard of Ruby.
I have perl code I wrote in 1992 that still works properly, without changes. The binary executables have changed ISA from MIPS 4 to x86_64, and are compiled fortran (gfortran). There's even a switch I use to be able to read the large endian binary files in gfortran.
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.
Are you kidding? Python code bases break week-to-week because pip is full of unversioned transitive dependencies, broken distro nonsense, and who knows what else.
As of 3.13, Python doesnt have a GIL either. JVM-based Ruby implementations don't have a GIL. Perl on the other hand never had a GIL, it just more or less defeated the purpose of threading by copying the entire interpreter state including all variables in every thread. Modules that explicitly work with threading are as rare as hens teeth on CPAN, it's almost always some flavor of async like Coro (hell I bet POE still works too).
python 3.13 most certainly has a GIL, it can just be optionally disabled, and this feature is in experimental status. see https://peps.python.org/pep-0703/
Oh, I thought the experimental state was earlier and that 3.13 was the official no-GIL release. Presumably it's going to eventually drop the GIL entirely (probably Python 4 if there ever is such a thing) but nonetheless I stand corrected, thank you.
I was curious about this and did some casual googling. It spawns an interpreter per thread. However, it seems this is not advantageous performance wise. From docs [1]
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.
No, instead they have subinterpteters with all of the massive overhead that brings re: data sharing. And even fewer CPAN modules are remotely thread safe than PyPi modules, probably in absolute as well as relative terms. That’s a low bar.
As a result, threaded Perl code or frameworks are extremely uncommon, even relative to Python.
I guess if the team is (only?) familiar with Perl. But then again, its the same with PHP. Even IF you know PHP you would not pick it over the more modern alternatives in 2024.
I guess some people just want to stick with what they know, and refuse to learn anything new.
I recently read a new idea of why PHP is useful to people - it's the lowest-overhead server-side Web page language available. If you want a tiny amount of functionality, you write a tiny amount of PHP and don't have to do anything else. So it scales much, much better in the tiny-to-medium-sized project range.
(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.)
> Even IF you know PHP you would not pick it over the more modern alternatives in 2024.
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).
I run a WordPress site for my wife's business. Would I pick it up again in 2024? Absolutely. It has nothing to do with what I "know", there's still no better CMS/ small diy e-commerce solution for, frankly, peanuts in hosting.
I really don't have much issue with modern PHP either, it gets the job done and unlike Perl is still very much evolving.
I think there are worse things than modern PHP (speaking as somebody whose primary contact with PHP is being traumatized by legacy PHP 7 projects). Afaik, the only places that will start a new PHP application today are places where the expertise is in PHP and Laravel/Symfony. I don't see a big enough benefit from migrating to a whole new stack that wouldn't be accomplished by some focused maintenance and refactoring if you're already working with PHP 8.1.
I write PHP for a living and I only write headless apps with Symfony and Laravel. Blade is an awful template engine with a primitive parser. Twig is tolerable, but for me nothing beats the DX of Inertia with Vue.
You are most likely right. I just fear spreading complexity everywhere. But I also want to take advantage of the vast compute available at clients. So, I am conflicted. Vue is probably a good compromise. Please share your best references on Inertia/Vue.
Only deployments of Inertia I have are internal code I can't readily share, but all it does is replace the very typical pattern of passing json-encoded props to a a blade template that contains a single React/Vue/Svelte component. Now you just return Inertia::render('My/Component', $arr) from your controller or route handler function, and you're good to go.
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 don't "start a new project" in Perl, but I certainly write a lot of Perl. Mostly one-liners and small scripts, and mostly throwaway. Perl is a very efficient language for string processing, thanks mostly to its built-in regex engine.
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.
I'm considering it. It might be a language that does not need constant changes because of useless churn. Especially now, with the Raku split worked out.
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.
It's been my first choice for 30 years for anything involving a lot of non-trivial work with textual data (Including xml, json, etc.). And one-liners and any quick throwaway script, of course.
All Perl code I have ever seen, has been "write-only". Just completely unreadable and it was easier to just look at the output instead of the code when converting it to Python to get actual maintainability.
You are getting downvoted, but for me, it is the same experience. It's a dead language, and we are switching to Python, that is far better to maintain for me and for all our new hires. I mean, Perl doesn't even has a debugger on Windows.
Not true by any stretch. I've used komodo[1] for more than 2 decades as a debugger in Linux, Mac, and Windows. More recently VSCode on all 3, for debugging.
Definitely not a dead language. A mature and stable language, which won't surprise you.
Perl 11 has been abandoned at least (5+6=11). Perl 6 features on perl5 without the incompatible syntax choices. I couldn't make inlining (cloning of subs) work, which is needed for realistic method calls. Their approaches got a it better lately, but still like 20 years behind mine.
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!
>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.
I remember learning perl in the early 90s, it was perl 4 at the time, and it opened up a whole class of possibilities by its incredible expressivity, things you wouldn't otherwise do because they'd be far too tedious in C and not really doable in sh or awk. Then perl5 came and extended it into a fully fledged programming language with modules, data structures, closures, the whole lot. And CPAN was unequalled for very long.
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 (!).
> One is the shifting sigils, accessing @x with $x[3] instead of the logical @x[3]
$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...
> > One is the shifting sigils, accessing @x with $x[3] instead of the logical @x[3]
> $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.
Perl has lots of weirdness, that's not surprising to anyone. It's still quite consistent in how it interprets sigils though, even if it's irritating (I don't find stuff like "@{$foo->{bar}}" all that beautiful either). It's not like there was some universal norm around sigils, programmers intuition is informed by the languages they actually use.
List and scalar context make plenty of sense once you wrap your head around them.
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.
Perl is still a better system administration language than Python. Many Unix wrappers in Python like shutil and subprocess are just not very good.
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.
Perl has a huge amount of terrible design decisions and low hanging fruit, yet it has barely improved over 20 years.
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.
I am feeling a different end of the Perl elephant. To me Perl becoming unpopular and not "improving" has meant that code I wrote in 2003 still runs today in 2024. And nearly all the code I write now will run on that perl interpreter from 2003. That kind of multi-decade stability is exactly what a system management (or personal codebase) language needs. It's an amazing boon for people who want things to just work and keep working.
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.
Absolutely perl's backward compatibility is amazing and makes other languages look like a joke. But it is arguably holding the language back from changing in any meaningful way.
> To me Perl becoming unpopular and not "improving" has meant that code I wrote in 2003 still runs today in 2024. And nearly all the code I write now will run on that perl interpreter from 2003. That kind of multi-decade stability is exactly what a system management (or personal codebase) language needs. It's an amazing boon for people who want things to just work and keep working.
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/
Years ago, someone would say "It is quite easy to write Python code that works just with all Python versions since 2.6. Easier than writing any Perl code..."
Perl requires a 'use version' statement otherwise your code can't use anything added since ~15 years ago. Python has no such system, so it's hard to know if the code is going to work on any given version of python. The core modules also seem to change much more often than Perl's.
> 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.
> I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly.
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.
That depends on "which version" of "Perl 7" you're saying, as IIRC there were various "factions" that had varying ideas about what ought to happen when "perl7" runs programs that didn't specify a "use v..." or that specified a specific "5.something" version.
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.
> 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.
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.
> 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.
Tangent: I wish more projects/build systems had a distinction between modes of “I'm the developer” vs “I’m just a poor soul trying to compile this”. -Werror is appropriate for the former but not the latter. It sucks when some random dependency stops building because they put -Werror in their makefile and the compiler added a new warning at some point that didn’t exist when the code was written.
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.)
> Why do I, some random person installing this module, care if the tests pass now?
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.
I think what you describe fits JS better. Already migrated your router library for your react project, this month? What, still not migrated!? No one is building things for X any longer! You need to switch to Y asap!
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".
Not just that, but cook kids change their languages weekly! HN is full of threads named: "<existing software> written in <language of the week>", and we all know how many people use that emacs fork written in ruby today, and how many will use the one written in Go in 10 years.
I'd say you're being a bit overly cynical. There's plenty of good news in Perl too. specifically, since you mentioned smartmatch, that's been pretty well fixed as of a couple of weeks ago with Switch::Right https://metacpan.org/dist/Switch-Right.
Switch modules have been around for years. There's Moo and Try::Tiny too. Some of this stuff should really be part of the language by now. Same with exporting functions.
Sure. I've been using the language for more than 10 years but this is dumb: different modules for every trivial feature that should be a language feature instead. Smart match is a perfect example. Smoothes off nothing. I'll be off using Ruby, thank you.
You manage feature differences one way or another. If you like choosing rbenv vs rvm vs asdf and then using them to manage your ruby versions and gem dependencies rather than having in-band switches in a single interpreter, great, you're welcome. I could even see someone making a case that it fits neatly within an org where systems/devops folks take more of the environments/dependencies division of labor.
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.
I use the system Ruby and don't have to worry too much about rbenv and rvm. 2.7 and even 3.0 is well supported. That's what I also did with Perl, except when I used MacOS which was a pain because of modules that used C libraries like LibXML. On Linux we can also use containers without worrying about speed penalty. There are sufficient solutions and okay tooling. Ruby's also got not one but two JIT compilers right now.
* 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.
Perl literally copied Python's object system. It's weird to describe it as less "native" than Python.
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.
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.
I use Perl full time and I know what they've added, but it's not a lot if you compare to other languages such as Python. Lexical filehandles were added in 2002. 'say' is just print except it adds a newline. Function signatures are a good addition, but that also took them about 15 years to implement due to bikeshedding.
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
More like 20. And pel6 is now a different language, raku, as they abandoned all hope to unify them. Even the community has splintered between perl and raku.
Perl has been called "the first post-modern programming language" by its creator and the motto is "There's more than one way to do it".
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.
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."
reply