With function signatures and state variables added in 5.010, I consider Perl feature-complete and have not really missed anything from it for as long as I've been writing Perl.
What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. The knowledge that the next minor release won't break existing scripts is underrated, IMO.
Solo project with ~23K LOC of Perl and counting here. Bless you, Larry Wall and Perl maintainers. Keep it up!
Edit: for those downvoting me because they don't understand my comment, it refers to the fact that bless is function of the standard library to associate an object with a class.
If you're downvoting me because you think it's a stupid and off topic comment, that is perfectly valid and acceptable to me.
One of my criteria for good tools is that they scale well from the smallest possible use case to absolutely massive. Git meets this criterion for example.
Anyway I manage a 250kline code base written over 20 years which is in surprisingly good shape consider it's age and how many people have touched it. Last time we upgraded the perl for the first time in a decade - going through the addition of many features and major internal changes (e.g. unicode, optimisation) the total number of lines of code we needed to change was at most 50. And very little having to fiddle with underlying cpan libraries.
Back to the point. Throwaway script - perfect candidate. Code capable of running the money pump for a billion dollar company. Also just as fine as any other similarly capable environment, better than some, trickier to manage the team than others.
Getting strings to have the right encodings should be easy. On the last Perl codebase I touched it's proven impossible for all practical intents and purposes.
Thanks for posting the happily ignorant code snippet that I have been waiting for.
The problem is that Perl internally encodes strings as sequences of numbers. Not even sequences of bytes, but sequences of numbers that could either be codepoints or bytes resulting from the encoding of such a sequence of codepoints. ...as a developer you are perfectly free to make this assumption any way you please at any given point in your codebase. It's not even clear that any one of those two is particularly "preferred" at large or a best practice or anything like that.
To make things worse, there is no way to know which is which, i.e. a string itself is happily ignorant about the assumptions that people will/should make about it. And Perl will happily concatenate strings making different kinds of assumptions, or double- or triple-encode them as you please, or decode something that hasn't been encoded in the first place.
This leads to jumbles of numbers that aren't anything in particular. They simply work well enough for sloppy programmers to not realize when they are making mistakes, but badly enough to almost guarantee that encoding errors will crop up on users' screens regularly.
Now, given that this is how the language works, be my guest jumping into a 100k loc Perl codebase that dozens of programmers have touched over a decade, passing around and munging together strings not just within their own codebase, but also using strings stored to and retrieved from elsewhere, in some case places where no one knows anymore where they initially came from or where they will ultimately go to.
> Thanks for posting the happily ignorant code snippet that I have been waiting for.
Thank you from being so civil. IMO displaying a badly encoded string beats crashing on a runtime error most of the time. I'd rather see "hôpital" than "Error 500", if you will. Maybe don't think your personal assumptions carry any validity out of your own choices, preferences, or uses.
I imagine the difficulty working with a huge codebase lacking refactoring and maybe even predating utf-8, but where would you be if it was written in Python 2.5 originally?
But that's precisely the point: Python 2.5 realized that something was fundamentally broken and the community went through a painful transition process. Transitioning to Python 3 meant getting your house in order where string encodings were concerned.
Any python programmer would tell you: Starting a new project in 2022 in Python 2.5 is professional malpractice.
But that's what the original post seems to be saying: That Perl 5 has somehow managed to fix any of what was fundamentally wrong with it. ...and that couldn't be further from the truth. And people in this thread are saying that maybe they should have another look into Perl 5 as a serious option for starting out a new codebase in 2022. ...and that's a very bad idea.
Sure: If you started out a new codebase in Perl 5 in 2022, there are coding standards you could adopt to avoid getting yourself into a pickle where string encodings are concerned. But without the interpreter helping you out on that front, it'll produce ugly code, and take mental discipline and disciplined code reviewing practices on a team. It's solving a problem that Python solves for you so much more easily and effectively. You could go with Perl 6 / Raku, but why would you? What does it have to recommend it over Python or Ruby, other than a Perl programmer's nostalgia for being a little Perl-like?
You could say the transition from Perl 5 to Perl 6 is just like the transition from Python 2 to Python 3. The difference is: Perl is simply late by at least a decade.
The point that the article is trying to refute, namely that Perl is for dinosaurs, in my mind just absolutely stands.
> But that's precisely the point: Python 2.5 realized that something was fundamentally broken and the community went through a painful transition process.
It's still not done for many, many projects. "python2" is still installed on 99% of systems I touch. Off the top of my head, the only machine missing it is my laptop, actually.
So your last perl codebase had the choice of not going through this painful transition process. Maybe it's what makes the best sense from a business point-of-view? "Worse is Better", remember, that's why we're running this sloppy Linux everywhere and not the almost-perfect OpenVMS or Genera.
>But without the interpreter helping you out on that front, it'll produce ugly code, and take mental discipline and disciplined code reviewing practices on a team.
"Ugly code" is in the eye of the beholder. For many a python project I'll have to add long series of elif or try/catch to check for the type of some incoming data returned from some API, where it could have been easily managed through duck typing in python 2.7 or Perl. Most programmers won't catch it until the error occurs in production, if the value returned switches types infrequently enough.
> The point that the article is trying to refute, namely that Perl is for dinosaurs, in my mind just absolutely stands.
To me, having to get my "house in order" without asking for it is basically non-consensual changes by the developer, and I think that is abusive.
With humans, my response to abuse is distancing myself from the source of the abuse, and with technologies it is no different.
Python is very popular, and I'm actually learning it right now, but I would not write anything important in it for another 20 years, since they just did ANOTHER breaking change in a minor version release.
> To me, having to get my "house in order" without asking for it is basically non-consensual changes by the developer, and I think that is abusive.
If you used Python 2 in a way where encoding errors wouldn't be an issue, and if you used the Python 2 to 3 conversion tool that they made when they released Python 3, then in most cases you didn't have to do any work beyond that. ...if however you used the tool and suddenly your code threw exceptions then, more often than not, the errors were errors you needed to fix anyway, even if converting to Python 3 wasn't something you wanted to do. And they gave you 11 years for making the transition between the release of Python 3.0 and the last release of Python 2.7.
I don't agree with that analogy about an abusive relationship.
It's more like a five-star restaurant asking you to please put on a shirt if you show up there in a bathing suit. It's just a norm, in this case cultural, that comes with five-star restaurants. If you don't want to follow it, you're free to go find a beach cafe somewhere.
> It's more like a five-star restaurant asking you to please put on a shirt if you show up there in a bathing suit.
But in this case, the restaurant had previously told me that a bathing suit is OK, and I've been showing up in a bathing suit for years.
They don't owe it to me to accommodate me, but they have just proved themselves unreliable, and I won't be going to that restaurant again, since they ruined my plans for the night.
...I agree, it's pretty obvious that this thread has gotten to the point where particulars don't matter any more.
As I recall, "bytes" didn't exist in Python 2.5 but were brought in in later versions of Python 2.6 and Python 2.7 when Python 3 already existed to provide a more continuous upgrade path for those still on version 2. You could get in the habit of using "unicode" and "bytes" and then the switch to Python 3 would be this "just renaming" thing. ...but that was the end point of the process, not the starting point.
I'm not an unreflected Python fanboy. I don't like many of the new developments since version 3.5. But I've spent 2003-2018 with Python as my main language, and 2018-2022 being forced to use Perl 5. And that has left me with the impression that Python fixed pretty much all of what was wrong with Perl 5 in a way that the Perl-community itself never managed and doing Perl 5 instead of Python 3 in 2022 is basically all downside, no upside.
I also admire how well the switch from Python 2 to Python 3 was executed, compared to how poorly Perl is doing in the switch to Perl 6.
I predict that the Python community is going to fall apart over the next 10 years over feature creep and losing its identity, trying to be all things to all people, with people subsetting it in different ways to get to a sane subset of the language, similar to how people are doing with C++.
The debate between weak typing and strong typing is as old as the hills. But in much of the modern era, strong typing, of which Python is an example, seems to have decidedly prevailed.
I think with languages like Perl, Ruby and Python you just need a static, compiled language to migrate to at a certain scale, preferably with similar features. Kotlin and Scala seem to be currently the best options for Ruby, Python and OO Perl. For procedural Perl maybe Golang.
> What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. The knowledge that the next minor release won't break existing scripts is underrated, IMO.
I don't write much Perl these days and haven't for some time, but it's still what I might reach for if I were tasked with writing something suitable for a scripting language that had to run with ~0 operational or upgrade/maintenance budget for a decade or more in environments I wouldn't necessarily be able to control or influence, or else [bad thing will happen].
My guess is that for many people it's hard to write non-obfuscated Perl code. It has so many operators and ways of doing things that walking into someone else's code may feel like having to learn everything from scratch.
In all honesty I have read more unreadable code in Python, than Perl. And I have written nearly equal of both over my career.
You can write bad code in any language. Bad variable names(sometimes single alphabet names), functions running pages long, duplicate code, algorithmically inefficient code, no error handling, master try/catch statements, OO abuse, functions with unpredictable side effects etc etc.
Early internet saw a flood of newbie programmers, and therefore a flood of badly written code too.
For that matter you also see badly written C/C++ code from those days. How do you think C++ got its reputation for being too bloated beyond practical use?
I’ve had very limited contact with Perl, but for scripting purposes it does seem like the best option, so I intend to sit down to it and learn it better. It looks like a great next step after sed and awk (perl -pe). I love the ability to write terse scripts, reasonable speed for a scripting language and, as you said, backwards-compatibility (such a stark contrast compared to Python).
Learning Perl is a classic of the form---the best intro programming book that I've ever seen, at least for smart readers who've done some kind of programming (any kind, with any language) in the past.
The contrast to Learning Python is noteworthy. The latter book is useful, too, but it's about ten times bigger and much less focused on introducing a language.
Learning Perl is a great book but for anyone new make sure you get a copy of the 7th addition. It originally came out in '93. The 6th edition is 12 years old now.
I would argue that ruby as almost all the strengths of perl and conciseness with more coherency if you want a perl-like fluidity and terseness. I personally like python for anything that becomes more than a 100 lines of bash.
Due to poor coding practices (eg monkeypatching) and a weaker testing culture (by default Ruby does not run unit tests when installing libraries) I've found Ruby to be substantially less reliable than Perl.
However the world has moved on to Python. So I curse every time I again have to look up how subprocess works for what I'd do in Perl with backticks.
To be fair to Python subprocess is not simply a substitute for backticks in Perl or Ruby. It's supposed to protect you from some of the more obscure problems which can happen with shell expansion.
A lot of languages allow the running of arbitrary code on install, so it is not particularly dangerous that Perl allowed it.
However you have no idea how many bugs got caught because the test run uncovered platform specific bugs. This is exactly what gave Perl a good name for being portable. Doubly so given that Perl always did this, starting back in the 1980s.
Even better is cpan testers who will run your cpan package on the widest variety of platforms I have ever seen. To my knowledge no other package ecosystem will do this.
I think that's the main thing preventing one from using ruby like this. It is otherwise preferable in pretty much every way.
Perl is kind of pre-installed on virtually every Unix-like system for what are at this point historical/legacy reasons. It is unlikely any other language can ever achieve this at this point.
Indeed. As much as I would like to use Ruby or Raku for this type of stuff, I keep coming back to Perl because it's simply... there.
Sure, I could probably install Ruby on any machine I want it, but it's not just technical availability. Socially, Perl serves as a quite obvious Schelling point. I don't have to convince four other people to learn Ruby, because Perl is what everyone would gravitate to even in isolation, again because it's just... there.
(That said in recent years I've had to switch to Python for some things aimed at a younger audience. Oh well.)
For that, there is Next Generation Shell. Also works like a charm even before 100 lines. For example when structured data is needed. Some other advantages over bash are error handling, automatic command line arguments parsing (similar to Raku, btw), standard library with functions like warn(), log(), debug(), retry(), etc that you have likely implemented hundreds of times in your bash scripts.
What is your project? Raku has some cool features and interesting syntax, I took a look at it before the rename, but find myself reaching for Python for basically everything.
Raku is a really nice language. I especially like the features that improve safety of the code: gradual typing, subsets, PRE and POST conditions, and defined/undefined checks. Junctions and multimethods are also nice. I have an article - not finished, and probably won't ever finish it, unfortunately - showcasing these features: https://klibert.pl/statics/raku/writeup.html
I think Raku deserves way more attention. Its implementation is suboptimal in many ways and it's improving slowly due to very small core team. With more exposure, more people would come, and hopefully some of them would consider contributing, accelerating the pace of development.
While it's not my favorite language. I have to admit that function signatures go a long way towards making perl feel somewhat normal to work with. I have to imagine they are pretty big boons for IDEs.
When was the last time this caused a bug for you? My experience of moving from JavaScript to typescript is that it takes significantly longer to write many generic things because the types can’t really express the intended use as well. I will certainly admit that types help a lot at the boundaries between systems , or for catching errors introduced when changing code, but it’s not always a clear win for types, given how much more verbose, and less expressive the language becomes as a result.
But of course, the study does not account for if increased development time cancel out revenue gained from lower bug count. (And this will be a difficult problem in general, due to first-to-market effects etc.)
This is my experience as well. I have a side project in its prototyping state and tried to use typescript in it. The result was exactly what I was afraid of - the first half of a weekend spent on fine-tuning tsconfig and tsserver integration, the second half on type acrobatics and investigating wrong narrowing issues. No code was written that day. I have a decent experience with both typed and untyped languages to see pros and cons of typing and am consciously choosing untyped for the “development” phase.
I agree with the first part (I generally hate the devops situation with JS, TS, nodejs, modules, etc). But I don't understand the part about type acrobatics. TypeScript's typing is robust to the point of being Turing complete, so you can express things that are generally not expressable in your typical typed language. And if TypeScript cannot pin down your types, it is probably a code smell. But you can revert to "any" at any time anyway, if you feel compelled to do some unidiomatic js trickery.
I’ve ran into situations where pretty obvious “if (typeof + condition)” chain over-narrowed a type so that further else-ifs were inferred as “never”. The logic was sound and triple-checked, I only struggled with convincing tsc that it’s okay. Sure, it was my fault somewhere in my types and not in typescript, but the progress doesn’t care which part of a development site fails or spends too much time in research.
unidiomatic js trickery
type Foo = undefined | false | Unit | Foo[] | FooObject
This was a part of the issue, afaiu. FooObject being “partial” either fell through obvious typeof guards, or removed other essential types from a branch, depending on what I tried. I ~understand why the issue persisted, but had no clear way to tell tsc what I mean there. The perspective to meet a similar issue in a much more complex case feels unpleasant.
While types make intents formal (which is a pro), they require to specify irrelevant edge cases. Dynamic typing serves as “code is law”, and when you meet an edge case in the wild, it’s much easier to explain it than to formalize.
I also remember many cases of prototyping in other typed languages and it never felt “focused on the job” to me there either, even when (or despite?) a type system wasn’t turing-complete.
Also, my best hope for typescript was that it would allow me to create type-only “header files”, which would serve as a source of truth and a sort of auto-validated documentation. It turned out that forwards are not first class citizens in ts, and it was sunday evening already, so I gave up.
Backwards compatibility for languages, libraries, environments, compilers etc. etc. is super super important. Without it no language/libraries/.. will be successful long term. Because people will simply switch to more modern offerings instead or not upgrade to newer versions. Making things “deprecated” is really bad. Just don’t. An API is forever. So ack accordingly.
> The 5.36 bundle enables the signatures feature. Introduced in Perl version 5.20.0, and modified several times since, the subroutine signatures feature is now no longer considered experimental. It is now considered a stable language feature and no longer prints a warning.
Oh, that's a bummer. I was kind of excited to use those, but since I never know when I'm going to get a call from the Centos 7 guys I have to stay away from features newer than 5.016. Basically just new enough to get semi-sane UTF support.
Thanks for the correction. I don't use them anymore (instead doing a few lines of sanity-check boilerplate in each sub) so that's why I made that mistake.
This may shock you, but: historically, Perl functions did not have declared arguments. Like, at all. The function just got arguments implicitly passed to it as an array (@_), and parsing that into individual variables was up to the function -- so most functions would start like this:
sub myFunction {
my ($self, $arg1, $arg2) = @_;
...
}
Or, in older code, you might even see this:
sub myFunction {
my $self = shift; # implicitly get the first value from @_
my $arg1 = shift;
my $arg2 = shift;
...
}
Notably, this didn't even check the number of arguments you passed. If you passed too many or too few arguments to a function which worked this way, the extra arguments would silently be ignored, or missing arguments would silently show up as undef.
Function signatures turn this into something that'll look much more familiar to users of other languages:
sub myFunction ($self, $arg1, $arg2) {
...
}
which includes checks to make sure that all the expected arguments (and no more) were passed.
> If you passed too many or too few arguments to a function which worked this way, the extra arguments would silently be ignored, or missing arguments would silently show up as undef.
This part probably won't shock anyone given the prevalence of JS today. Which is kinda sad, given that it's 35 years since Perl was first a thing.
Lol there were places, perhaps times, where Perl subroutines would "shift" as they go along, to create a prose effect. Sometimes you'd get a comment about it, but mostly not. Maddening for any longer function.
> What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility.
Is that even something they're doing on purpose? Didn't they completely botch their attempt at a new major version?
When Python moved from Python 2 to Python 3, introducing breaking changes, there was enough velocity and acceleration in the Python ecosystem for people to be willing to take the pain.
With Perl it's inertia. So even if the language designers and package maintainers wanted to make breaking changes, they couldn't, because people would just stop updating. All that's left to do is to drag out the process of this ecosystem rotting away.
> When Python moved from Python 2 to Python 3, introducing breaking changes, there was enough velocity and acceleration in the Python ecosystem for people to be willing to take the pain.
Paint me unconvinced. Python2 is still a thing, 14 years later.
When I was about 20, I went to the local Barnes and Noble to find a book about programming.
Picked up the O'Reilly Javascript book from around 2000. Had no idea what javascript was, just wanted to learn how to program and trying to pick the most popular language.
$40 later, I got home and started reading! Very confusing, the first half of the book covered the language runtime (I think?) and the second half covered the browser sandbox, and it took me 200 pages to realize that I can't easily read or write to files on my machine with this language. Not what I was hoping for!
Back to Barnes and Noble, another $40 and I came home with the O'Reilly camel book, Beginning Perl I think? Cover to cover read, probably the last time I did that with a programming manual.
Decades have passed, I'm in the same camp as those that prefer Ruby now, but man what a breath of fresh air Perl was back in 2000.
That would be "Programming Perl" by Larry Wall. For me too it was the only programming book of that size I was compelled to read cover to cover. Larry is a great writer but maybe that's to be expected from a linguist. If Python is the number cruncher's favourite language Perl (and subsequently Ruby) must be the linguist's favourite. I got into programming after being intrigued by regular expressions in the advanced section of a chapter on Search And Replace in Dreamweaver 3 Bible back in 2000. At the end of the section there was a footnote to Jeffrey Friedl's "Mastering Regular Expressions" which I read cover to cover. Most of the examples were written in Perl as it was the only language with regex support so deeply baked-in so I had to then go to the source - "Programming Perl" by Larry Wall.
I don’t really miss perl. I do miss the period when perlmonks was relevant to me. I haven’t really seen a similar community since. Maybe rose tinted spectacles on my part but i learned some really enlightening algorithms on there specifically in text processing and i recall it being a really warm community.
Randall Schwarz used to run a podcast that was a total goldmine. Fond memories of listening to that on the train on the way to work.
I miss perlmonks as well, now that I do mostly python. It was like stack overflow, except discussions were encouraged. It gave you far more understanding than copying a SO answer usually does.
It's not objective, but I find I have more fun in Perl than any other language. The initial jump was steep, but it helped that I already knew some shell. Now I think in references, I can guess what $_ is going to be, I slap in a big, my $val = s/<RE_HERE>/other_thing wherever I want, I could go on!
I think $_ belongs to a different era, before levelling everything to the lowest common denominator became seen as a good thing. I found the limitations of its rivals less than compelling, and besides JavaScript is arguably more complex than Perl these days.
A few years ago I pulled out Higher Order Perl and started playing with some of the advanced features/techniques available in the language. And it was really fun! I think Perl was the first popular multi-paradigm language.
I've used Perl off and on throughout my career, even working at one job that was pretty much exclusively Perl. I've also used Java and C/C++. I've done a lot of work with embedded systems where C was the order of the day.
But back to Perl. I always thought one of the best things about Perl was CPAN. I could nearly always find a module that would accomplish a specific task I needed and then I was just left to write the glue to implement that function (or functions) for my particular needs. I'm surprised CPAN is not mentioned. I wonder if it is still active. I also wonder about security of CPAN in todays environment. I find stuff like pypi and npm to be pretty scary.
I haven't started anything in Perl in quite some time. All the cool kids are using Python so I've been sharpening my skills with that. (But it's all hobby projects these days.)
> But back to Perl. I always thought one of the best things about Perl was CPAN.
I'm a younger developer, so I wasn't around when Perl was super popular. I listened to the Corecursive episode about CPAN [0] and was really impressed. It's a good listen even if you're not that interested in Perl anymore.
> nearly always find a module that would accomplish a specific task I needed
Then you didn't have to write PC/SC smartcard code in Perl. Also most of the MQTT clients are crap, only Net::MQTT::Message is useful but then you have to write the network client yourself and if you also need TLS, good luck, the modules doing that have like 200+ failed tests. CPAN is great but if you need anything out of the ordinary you'll probably find modules in a state of disrepair, abandoned in 2010.
That's unfortunate but I suppose a consequence of a less active ecosystem. I don't recall dealing with that back in the day but it doesn't surprise me now, particularly with more recent technologies like MQTT.
I have written MQTT clients in Python and the module support was good. But then I discovered it was easier (for the most part) to use the Mosquitto cli utilities and pipe stuff to/from them. For cases where that was awkward, it was easy enough to write in C and use the PAHO libraries directly.
Yes, Python, Ruby and JavaScript have better MQTT libraries. I managed to write an async Perl client using POE (the networking code was already heavily using it, otherwise I wouldn't even pick POE since it's awful and also dead) and Net::MQTT::Message. Piping output into mosquitto_pub/sub was out of the question, since this was no hack but rather a service that streams data into the broker.
I suspect writing it in Ruby with async would also prove problematic, but there are the ruby-mqtt and async-io gems and one would use the MQTT::Packet for formatting messages and Async::IO for the networking code. Still a lot less painful than what I did with POE and Net::MQTT::Message.
MQTT.js is async already, you just import and use it in the browser, Node.js, probably Deno as well. Easy. It took literally five minutes to get the client enpoint working in the browser over WebSockets. One could even do it from the browser console.
The thing is back in the day 35,000 modules on CPAN was a big deal but if you look at https://modulecounts.com that's since been dwarfed by Python/PyPI (398,000), Ruby/Rubygems (173,000), PHP/Packagist (351,000) and JS/npm (2,116,000).
CPAN is still where the most interesting work is happening with Perl. Often blog posts like Dave's here will highlight features added to recent perl versions, which from outside the community looks pretty underwhelming. Probably it is, but that isn't as compelling as what you can get from outside the core.
While the core devs of perl concentrate on optimisation of the language and slowly add new features, the strong backwards compatibility approach constrains what can be done with it. The backwards compatibility is so important that development builds of the core will run against the entirety of CPAN's distributions' test suites to see if changes break anything there. This is know as "BBC" - blead breaks CPAN. If a change breaks something on CPAN then it needs to be reevaluated. I don't know if any other languages have an equivalent - running not just the internal test suite but also an enormous external one?
The nature of Perl means external modules can bend the language in some pretty interesting ways and build atop a strong foundation. The new features added to the language are slowly being used by more module authors to create features and libraries that are what you want to focus on.
I am not much into JS but I have seen countless jokes about JS/NPM having so many modules. I never understood why JS/NPM ecosystem has so many modules? I guess JS isn't that versatile language.
I still use Perl whenever I need to get something complex done quickly. Whether it's the handy command-line switches and features for easier one-liners, or just easier stream text processing, or easier external command execution, or the huge library of modules that often support things Python doesn't, Perl is my "fuck it, I just need to get this done" language.
I can't wait for the day that programming languages as a concept are obsolete. It feels exactly like hand-tool woodworking. I would love to stop building tables and chairs over and over, instead just buy them from Code IKEA.
For me it’s any kind of text processing; especially code generation for some one-off task, like churning out SQL or bash scripts/shell commands. Faster than doing it by hand. __END__ is one of my best friends because I can dump the input data right into the script. On the rare occasion I am irked whatever language I’m working in does not have format/write, which comes from the Fortran tradition iirc.
"Bare bones" seems to be a good thing for Perl. I use Strawberry Perl on Windows and it is orders of magnitude faster than Powershell for processing large files of text strings using regular expressions.
I hope the addition of a "new object-oriented programming framework" won't take away the "bare-bones" speed of the current release.
I think this is where Ruby's reputation for being slow is a bit misleading. Perl is faster because it doesn't have OOP baked-in. Pre-load Moose and Perl's performance isn't that different than Ruby's.
Honestly, I don't know, but I would assume Ruby's OO performance is better than Perl's with a very large extension (Moose), where some optimizations just aren't possible, given the core architecture of Perl, but I'm really getting above my pay grade in what I know about Perl internals (which is almost nothing, really, that's some scary looking stuff in there!).
I do look forward to the new class system coming to Perl based on Corrina, but I also can't comment on how performant it's going to be, either. My guess is that going ahead on this large project was based on answers to questions like, "is it going to be more useful than Moose?" "More performant?" Because if not, why not just use Moose?
Don't worry. The Perl community, which I love BTW, has bee fighting over Moose, Mouse, Moo and the inclusion of a Meta Object Protocol in the core since the mid-2000s which, I would argue is partly responsible for its decline. So for Perl OOP will always remain an option unless you count blessed hashrefs.
Really? This is interesting! I had completely written off Perl for Windows due to its heritage. But we still use COM objects in our scripts here and while I like PowerShell conceptually, I really never got to have fun with it as a scripting language. It just has so many quirks like “implicit returns” etc. and is just so verbose it’s bordering on hard to read at times.
While you can use them, I do not recommend it. The problem is when you want to convert a script into an EXE so not everybody has to install Strawberry Perl. Apparently some viruses are written in Perl because Windows Defender flags any exe you build as a virus and deletes it. Also, changing the application icon doesn't work, so you're always distributing a Camel app.
It's a shame too because as you say the Win32 API stuff works great up until the antivirus kicks you in the nads.
True, but people are going to be calling you, not Microsoft, when the app is instantly deleted when they download it. The worst part is that it isn't even consistent. It will be ok for a few months and then end up back on the virus list again.
Perl enabled me to take a business-owner's disorganised national spreadsheet of teachers, locations and contact details and turn it into a web application, freeing him from fielding phone calls all day and boosting conversions over a period of 15 years. Perl's superb regex handling was essential in extracting and gradually refining the data until it was fit to be entered into a database. From that point on Perl, along with PostgreSQL, literally ran the business while generating opportunities for hosting promotions with bigger companies. Those who (m|kn)ock Perl usually haven't spent a significant amount of time using it to add real value to a business.
Maybe I’m missing the point of this piece, but it’s probably because I’m still reeling from the author’s idea that adding “say()” which is “print()” with a newline added, is somehow an improvement to the language.
The point is not about `say` itself (which has been there since Perl 5.10, released on 2007/12/18), it's only an example of how much Perl uses modularity (via `use`) to enable new features while ensuring a) code dependent on a new feature alerts on Perl versions without the feature and b) backward compatibility of new Perl versions with old Perl code.
Compare:
# Perl
use feature 'say'
vs:
# Python
from __future__ import print_function
Which at first blush follow the same principle, except that Python decides that `from __future__` is a vision into upcoming doom, that is a future version of Python for which code that preexists becomes incompatible unless it is ported to the new version.
IOW py2 code doesn't run on py3, barking at you in obscure ways if you try, and py3 code doesn't run on py2, barking at you in obscure ways if you try. (or worse, partially runs and either explodes in mid flight or silently corrupts data).
Whereas Perl code written targeting vX runs on Perl vY as long as Y >= X, and if Y < X then Perl tells you "unsupported feature foo" or "your perl is too old, update to at least X".
$ perl5.18 sig.pl
Feature "signatures" is not supported by Perl 5.18.4 at sig.pl line 1.
BEGIN failed--compilation aborted at sig.pl line 1.
(yes yes I am aware that with enough effort and trickery you could write code that works on both py2 and py3. I did that a long time ago; it's a pain, and doesn't solve the problem of preexisting code)
And not just that, Perl alters its parser behaviour live (and scoped to the module!) so remove `'signatures'` from `use` and you get:
$ perl5.30 sig.pl
Malformed prototype for main::my_subroutine: $foo, $bar, $baz = 'fury' at sig.pl line 7.
But leave it in and there's no parse error. No magic preprocessed comments or fake code trickery like JS (which has a commitment to backwards compatibility as well) has to do[0]:
To invoke strict mode for an entire script, put the exact statement `"use strict";` (or `'use strict';`) before any other statements.
(They had to make it a string in void context instead of a comment because comments are removed by JS obfuscators, but it's essentially a magic comment/preprocessor directive)
At the $dayjob, writing some python assuming late model 3.10.x, and discovering that the API has changed when I have to make sure it works on 3.6.x and 3.7.x.
Nevermind important libraries like pandas changing the API so some functions you 've used for years just disappear.
I've got 30+ year old perl 5, that just works. And is readable. I wish 2 year old python could just work.
Say what you want about Java, but back- and forward compatibility have always been a big priority and part of its success story. No Java developer would be surprised at 30 year old code just working (ironically, it's more likely than for 10 year old code).
I'm working in Windows (employer's choice) and need to process some huge data files on the desktop.
Perl (Strawberry Perl for Windows) is much faster than native Powershell (or CMD) scripts. A few Perl one-liners and I have 2 GB processed in a couple of minutes.
> A few Perl one-liners and I have 2 GB processed in a couple of minutes.
This matches my experience: my task is IO bound, processing tens of GB in a matter of minutes.
> I'm working in Windows (employer's choice)
Work prefers MacOS, Windows is my personal choice :)
Windows 10 and 11 are a pleasure to use: between the Windows Terminal and tools like AutoHotKey, there's no Linux equivalent, even for a commandline geek.
Using Windows (and Perl, and other weird things I like) may not be fashionable, but it's hard to beat.
Full disclosure: Work has been Windows centric, but I recently moved to a new group with some Mac users. I'll have that choice, next time I swap hardware, but probably will stay with Windows because
* Would miss too many amazingly useful utilities like arsclip.
* Easier to patch into my home network, which is NTFS-based.
* Employer is now wedded to Microsoft and Azure, so having Powershell and native access to NTFS AD on my native desktop is proving more useful.
* I actually like the Windows interface, even with the Control Panel and other system utilities caught in a weird split between Windows XP and WIndows 10 UIs.
* Some things, like certificate management and hosting a personal database, I do in Ubuntu or Debian as a VirtualBox guest under Windows.
* Wife uses Windows on her laptop. She doesn't know it, but it's actually running as a VM on Debian, very stable, and can easily take her Windows to a new machine.
* [I keep coming back to add items to this list] Remote Desktop Services have improved vastly, and I can manage remote servers or 12 year old client machines at a remote site with equal ease. (XP/7-era machines got a second life when I converted Windows OS disk to SSD). Also find screen sharing via 3rd party VNC (TightVNC) useful.
* The keystrokes have become second-nature. Try as I might, I can never get fully comfortable on a Mac OS desktop. Now get off my lawn.
> The keystrokes have become second-nature. Try as I might, I can never get fully comfortable on a Mac OS desktop.
Same, that's one of the biggest reasons - but I also agree with the rest of your list: what I like the most in Windows is the UI! I run most of my programs fullscreen, with shortcuts. I rarely use the mouse, and Windows plays along, while I have to fight other systems.
Even when run baremetal, Windows has improved so much over the board that once you add RDP/VNC, it's a no brainer.
> > A few Perl one-liners and I have 2 GB processed in a couple of minutes.
> This matches my experience: my task is IO bound, processing tens of GB in a matter of minutes.
Huh. Windows is usually anywhere between bad to horrible at IO compared to alternatives. 2GB processing (usually mixtures of regex, summarizing data, summing fields extracted) shouldn't take more than a few seconds. Even on a slow disk, say 100MB/s, we are talking 20s. On faster SSDs, and NVMe, its very snappy.
If you are waiting minutes ...
> Windows 10 and 11 are a pleasure to use: between the Windows Terminal and tools like AutoHotKey, there's no Linux equivalent, even for a commandline geek.
Huh. I'm happy that $dayjob gave me the option of getting off my horrible Dell workstation laptop (8 core, 64 GB ram, nvidia graphics) and onto a mac pro m1. While the keyboard diff is annoying, karabiner elements fixes most of that. I still ask for a linux laptop at ever opportunity though, as this is what I'm most functional with. Easily the best/fastest experience I've had for dev/admin, and the most stable. Mac is a close second.
When you refer to modern hardware with vectorization, are you saying perl beats software that makes use of vector instructions? If so wow! Afaik perl is a plain old interpreted language with no JIT, what makes it so fast? I had an idea of perl as in the same performance category as Python, Ruby and friends.
My assumption (and I could be wrong) is that whenever you do something that's ultimately CPU intense, perl dives into C code. The sort of stuff you do with perl tends to be a lot of string manipulation and it turns out perl is pretty hyper optimized for that sort of workload.
Other languages could do the same, but often they have a few more layers before they start running that C code.
I'd be curious to know if the perl grammar also somehow lends itself to being fairly optimizable for it's interpreter.
Perl does a kind of half JIT when you start a script. It doesn't compile fully down to native machine code, but it does parse and lex the script to build an internal representation. The code is then interpreted, but since it doesn't have to parse each line again it runs very fast and also you can interpret code on the fly in a variable so you get the best of both worlds.
This has been the usual way to implement interpreted languages for decades; Perl isn't special in that regard. JIT generally refers to generation and execution of native code specifically.
> What's the difference when compared with other scripting languages?
Compared to every other scripted languages I've tried, it's always faster - so much that it often rivals compiled code (even with extra optimizations as explained before)
> Is it just all-around faster
Yes - also faster to deploy, and harder to break in deployment due to dependencies rarely evolving. No need to pip install whatever.
Consequently, tracking modules' versions (say in python) and their break in compatibility is a thing of the past. Some may say it's because it's dead. I guess I'm a necrophiliac then, because it makes my life so much easier that I'm loving it :)
Uh,those features are here for almost decade now, some longer IIRC.
But man, just being able to write
use v5.10
have been a blessing when you need to support some legacy infrastructure. Old Python broke after upgrades, Ruby broke, but Perl code keeps on trucking.
In vast majority of cases the code changes were just "well, the new version of lib gives some warnings about deprecation, might as well clean it up a bit". The minority of cases has been Mojolicious breaking stuff again.
Please don't blame bare word file handles on "C heritage"
--
Some of the improvements were needed because in places Perl’s Unix/C heritage shows through a little more than we’d like it to in the 21st century. One good example of this is bareword filehandles. You’re probably used Perl code to open a file looking like this:
> Perl receives such an unnecessary amount of hate
I agree. We might deny it, because we are geeks, not fashionistas, but there's such a thing as "cool for geeks" like running Rust code on MacOS with some PostgreSQL sprinkled on, and such a thing as "uncool" like running Perl code over Windows and exchanging CSV files.
Personally, IDGAF: I care about what works the best, not what's cool. I care about performance. I care about the code not breaking due to weird compatibility issues. I care about keeping the stack as simple as possible, because what's simple often works better.
If, god forbid, I need something more complicated than CSV, I reach for sqlite --- which, unfortunately, is starting to become the "cool" option, and therefore might get turned into the proverbial hammer that makes all your problems look like nails!
If your system isn't performant, it's shit. Performant is relative to what you're trying to do and how picky your users are, but at some point you're going to be optimizing for milliseconds without question.
Programming fashions are different from regular fashions in that they're about functional characteristics like reliability and readability. But they're like regular fashions in that they're about social perceptions of those things.
I don't think it's hate. I think it's more "why would I choose Perl over Python?" Perl has a painful syntax, Python greatly improves on this with easy syntax. I don't want to have to relearn the syntax every time I reach for a scripting tool.
> Perl has a painful syntax, Python greatly improves on this with easy syntax.
Regular expressions are way better in Perl. I increasingly find myself going back to Perl for RE heavy projects because it's so cumbersome in Python by comparison.
I'm still undecided on if Perl needing semicolons everywhere is only 'as bad' or 'worse' than Python forcing you to worry about the exact number of tabs/spaces indenting lines, but I'm leaning toward python being easier in that respect.
Still, when I have to get something done quickly, especially if it's an immediate need I don't see having to worry about later, Perl is what I turn to. Everything in Python becomes a "Project".
> Perl has a painful syntax, Python greatly improves on this with easy syntax.
That's a matter of opinion. C style languages are a lot easier for me than whitespace significant languages; my editor will go to the matching bracket with ^G, but I can't do that with whitespace to get to the end of a block. The type sigils are a bit tricky to figure out, but if you spend the time to understand it, it makes sense (but that's also a mater of opinion, too).
Nobody complaining about Perl's syntax is complaining about the "C style". Reading the arcane incantations of magical $ variables gets really old really fast, Perl takes the "if it was hard to figure out then the code must be hard to read" to a whole new level. It's probably the only mainstream non-functional language where you can be absolutely unable to decypher a snippet of code even though you know another C-like language.
> Perl has a painful syntax, Python greatly improves on this with easy syntax.
I use Python and Perl. Some people who like Python want everything to be Python and "hate" anything that isn't Python. It approaches zealotry in some cases.
Perl syntax is expressive and is similar to C, C++, Java, and yes Bash. These are successful languages too despite not being pythonic.
Sure, if you're a fan of Java verbosity. Since PHP 5.3 I don't know why Zend didn't just re-brand PHP as Java Lite. I also don't get why Rasmus allowed the Zend team to get away with it since at heart he's a procedural C guy.
Python was an obscure algorithms language until Google standardized around it, if they hadn’t we wouldn’t be talking about it. Not to say it’s good or bad since that’s silly and evaluating languages is complex and context sensitive, but IMHO Python isn’t popular because it’s great, even if it is.
Badly-written Perl code from the 1990s is not the fault of the language.
It's the fault of the non-programmers who read "Learn Perl in 2 hours and become a millionaire" books, had a massive s*t on a keyboard and started a business with it
And yet those non-programmers who instead "read "Learn Python in 2 hours and become a millionaire" books, had a massive s*t on a keyboard and started a business with it" tend to have ended up with something significantly less horrible to maintain.
It really has to do with the "programmer" and not the language.
Those learn to program and make fast money books were a product of the 1990s, and they appealed to people who cared more about making money than about producing any kind of product.
For example, I once had to fix some code that was supposed to delete files that were sitting in a directory for more than a week.
Rather than do something sane and simple, like look for files where the mtime was less than a cutoff and delete them, it looked for files where the absolute difference between the age and 7 days ago was 0. So it had the side effect of deleting things that were 7 days old, or were less than a day old. It also missed things that happened to be older than 7 days old.
(And nevermind that it was written because people couldn't bother to figure out why files were stuck in the directory.)
The company's codebase was filled with nonsense like that.
The person who wrote that would not have written anything better in Python or anything else.
But from the outside it worked well enough and they made a lot of money.
I slowly switched from Perl to Ruby for writing my own text processing scripts. A loop with <> is very convenient but I was using Ruby for work (still do among other languages) and Perl for nothing. I was forgetting how to do stuff in Perl.
So, this is on the stack overflow blog. And Joel Spolsky famously thinks that to rewrite a codebase from scratch is the "single worst strategic mistake that any software company can make" [1].
I wonder if this is how you end up being a Perl user in 2022.
Eh? He's not wrong. for any serious (in production and actually being used by paying customers) software it _would_ be crazy to rewrite a codebase. I can't think of a compelling reason to.
For the record, I became a perl user (for fun!) in 2022 because I was attracted to the text processing capabilities, the awesome documentation, the baked in regex handling, the way it's so integrated into unix culture, the fact that it feels like a nice and natural step up from awk or bash when I want to process text files or work with the filesystem, and also the fact that I just find python so boring.
Oh, also Perl is a very powerful command line tool that can be easily piped into on linux. I don't think python or ruby are as powerful in that regard but I could be wrong.
It's wrong when stated as a blanket statement like that. It depends on the particulars of the case.
I've worked in a company that's taken this dictum as gospel and took it to its absurd extreme where refactoring of any kind was forbidden.
I would explain some dark corner of the codebase and everybody would basically agree that it was in bad shape. I would then explain what I wanted to do about it and people would say "Is that a refactor you're suggesting?" in a tone of voice that would be more appropriate when saying "Is it killing babies that you're suggesting?"
As coincidence would have it, that was a Perl shop. So I speak from experience. And that experience has left me somewhat scarred.
Imagine working on a codebase where any mistake you ever make you're just stuck with. And it's not just your mistakes, but other people's as well. And the mistakes just pile up and pile up and start interacting with each other in nasty ways and there's just no way out. I love being a programmer, but there is little in the world that I hate more than having to be a programmer under such circumstances.
What's more is that the financial benefit of not refactoring is a benefit that usually accrues to those who are in power in a company and who don't have to touch the codebase, whereas the psychological cost of not refactoring accrues to those who have no power who are forced by the others to wallow in the muck. -- That's the thing that Spolsky consistently just doesn't get. He consistently represents the one-sided view of someone "in power".
As a programmer under such circumstances, it really makes no sense to throw away your psychological wellbeing so that your company's owners can make more money, just like it doesn't make sense for a miner to give himself lung cancer so that the owners of the mine can make more money.
Conversely: If you're the owner of a software company (or mine, or whatever) you should partially think of refactoring as an employee benefit that will pay for itself through increased productivity. It's a point that's very convincingly made by Tom DeMarco in his book "Peopleware" [1]. Asking your employees to dial down the quality of their output so you can realize cost savings almost never makes sense when you take into account the human side of the economic equation. You'll demotivate them and the losses in productivity will outweigh the cost savings.
I'm not against refactoring at all! Refactoring is good! (Is Joel Spolsky against it? That _would_ be crazy). Refactoring in my opinion is very different to rewriting an entire codebase/application (which I assumed you meant - perhaps incorrectly?)
I'd argue perl's major value is from stability in the sense that what the perl developers write today can be run on the perl available on any machine, new or old. If a lot of perl developers end up use'ing lots of these new features that feeling of compatiblity will go away.
If you need new code you write today to run on 20 year old systems, don't use the newer features. Perl 5.36 is backwards compatible to code written for Perl 5.6 after all. If you need 20 year old code to run on new machines, the same thing occurs - you hand it to a recent Perl 5 and it works. Compare and contrast the last 20 years of PHP or Python.
Probably not the place to ask, but some of you might find this interesting enough to take pity on me.
I had an idea years back to build crosswords on the surface of a truncated icosahedron (https://i.imgur.com/qlLl434.jpg) but I had no idea how to find sets of 5-letter words that would mesh like that. A very clever programmer friend of mine whipped something up in Perl over a weekend using hashes. Basically it pre-emptively runs through the dictionary and hashes all wildcard forms of a word back to the original word (l...s->leaks, etc), then at each stage of filling out the puzzle it just grabs the list of words that hash to the current pattern. Say you're looking for something that fits s..p. it would return [stops, swept, soupy] etc, then tries each recursively. If the list is empty, there is no solution at that level so it backs up and tries the next word at the previous level.
I learned enough Perl to be able to make the code able to accept different polyhedra. The program takes quite a while to run on larger models, like say the rhombicosidodecahedron, so I've been looking for ways to speed it up. My background is with assembly and embedded C so I'm sure my implementation of these hash lookups would be slower than Perl's. Are there any other, maybe compiled, languages that have fast hash lookups like this?
Nowadays I have my own startup and my code is a mixture of JavaScript, TypeScript, and Rust.
Rust is good for anything sufficiently complex that you want to run quickly, have a small footprint, and want to be sure it works, while allowing for easy refactoring due to the strong type safety.
JavaScript is good for anything you want to write quickly and the code quality doesn't matter as much (e.g. test scripts). It's also much easier to write than Perl syntax-wise and has great async support (unlike Perl). Also it has a much larger ecosystem of libraries and easy to use in IDEs like VSCode. Obviously JS/TS can also be used in both the frontend and backend which is another big advantage.
TypeScript is sort of in between - if the JS codebase gets too large it should be written in TS instead. This makes the code less "write-only".
Perl and PHP were pretty good solutions as scripting languages until JS added good async/await support, map/filter/reduce, and destructuring syntax in my opinion. JS probably requires the least lines of code to get a program working.
I spent the last 16 years of my career using Perl for about half of what I wrote.
And I read the article.
The title makes no sense. The article show anything meaningful as to why Perl has improved and is "not your Grandfather's Perl". Most of what the article talks about has been around for over a decade. If anything, it shows that Perl really still has under it the same old decrepit beast it always been hiding away.
Looking forward to v7 and intro docs that only use "even more" Modern Perl.
For a bigger push, we should all volunteer on those "Do X in Y" language sites and add Perl examples. Same with Amazon Lambda and other opportunities where pick your language is available.
Also a modern OO seems nice, though not sure what is in it.
Would also like to see a default async library (maybe POE, but I never used it and find the name a bit strange for a default...but then I like Tokio...) Not my area at all, but an opinionated way of async seems nice.
I'm surprised with the emphasis on new features that such old features were highlighted. The 'say' function was added in 2007. Signatures were added in 2014, though to be fair they didn't stop emitting an "experimental" warning until this latest release.
I skimmed the article looking for a mention of a REPL or a new debugger. Perl is a great language but it lacks these tools. Sometimes I just want to try a couple of lines of Perl code in a REPL, but I cannot. Instead, I need to create a file. Also, when debugging with `perl -d`, I cannot use the Up arrow key to get the previous command. Not a big deal but the coding experience will be significantly improved with those tools.
``As shipped, the only command-line history supplied is a simplistic one that checks for leading exclamation points. However, if you install the Term::ReadKey and Term::ReadLine modules from CPAN (such as Term::ReadLine::Gnu, Term::ReadLine::Perl, ...) you will have full editing capabilities much like those GNU readline(3) provides. Look for these in the modules/by-module/Term directory on CPAN. These do not support normal vi command-line editing, however.''
Perl's concise syntax makes working in a REPL a pleasure. Python has a REPL but the design of the language makes it expand both in length (for loops) and in width (tabs).
I am a recent convert to working in a REPL first to test programming ideas.
I think that 'perl -d' needs to have Term::Readline to be installed to provide line editing. Otherwise you could use DDD, which provides an ugly but functional GUI to gdb, and perl -d. Or ptkdb which is better IMO ('perl -d ptkdb', requires the module and Tk).
Spent about 4 weeks learning perl at an internship 10 years ago. I believe that is one of the biggest professional mistakes I ever made. There is literally nothing I would recommend doing with perl over python.
I wasted the entire internship writing horrible perl code and not learning how to do anything that I would use later. This was early enough in my career that it had a lasting effect on my perception of software development and it took me 3+ years to get back "on track".
I think of Perl as a Python-PHP hybrid. A pragmatic product of its time that will endure, and while I'm grateful for never needing it, I'm glad that it's a solid option still for those who do.
I recall seeing my first PHP/FI page in the middle 90s. PHP was a godsend after you'd suffered with Apache's "server side includes" [0], which is largely what it was used to replace.
Python's origin was as a teaching language (originally ABC I think?), and thus the simplicity of the syntax. It was kinda cool that Python was around for so long before it took off... I had the O'Reilly Python book way back in the 90s.
Perl's influences were awk, sed, bash, C, Fortran, and Lisp.
I used to write automation for systems management with an old IBM product called Tivoli.
It was the best job ever. The systems monitoring tool used ancient Perl4 (this was circa 2001 when Perl4 was like a decade old) and Prolog to handle event management.
Sorry, but what? The top features they highlight here are a print statement that adds a new line, a change to the bonkers default of creating some kind of implicit global named variable every time you open a file, representing time as an object (with a strftime function!) and… function signatures?
I wouldn’t call this as “Perl moving forward”, I’d call this “Perl is still about 20 years behind everyone else”.
Wait until they find out that other languages print statements let you customise the line ending!
The `print` statement in perl has always behaved more or less as it does in the "other languages" you describe.
`say` removes the need for anyone to write their own "I'm tired of the manual newline ritual" function and provides a standard for where the newline is added. That's a marginal convenience, but given the frequency with which people either do write their own or newline inconsistency gets encountered (or both), it's a reasonable one.
And it's in pieces like this one not because it's a huge thing to crow about, but to illustrate the opt-in nature of incremental changes or sets of changes to perl.
`say` is also about 15 years old, like Time::Piece. The author is not announcing features that are new to the whole world, just new to a certain audience, possibly including the author.
This is also true of the filehandle scoping feature (which is 22 years old). If you find the old bare filehandle scope behavior only notable enough to hurl a drive-by "bonkers" at it then I suppose that's one way of advertising that you haven't spent much time thinking about unix shell utilities and associated features/issues.
Function signatures are slightly younger than typescript, or at least, the most familiar syntax for them; both the old and more recent means are essentially naming a list of arguments.
In general: perl is an opportunity to think about programming languages differently. There's a lot of contexts in which I never use it anymore, but it's rare to find people with substantial insights who casually disparage it.
Ya those were my thoughts exactly, and I used Perl heavily for several years.
The number two feature they listed was released more than 22 years ago.
Perl is fine for certain tasks, I have no problem with people who choose to use it, but at a certain point I'd argue it's better to learn a new language than try to use Perl for a new type of task.
>“Perl is still about 20 years behind everyone else”
The version of Perl on your favorite Linux distro might be. I think that's the point the article was trying to make...that distros ship VERY old versions of Perl.
What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. The knowledge that the next minor release won't break existing scripts is underrated, IMO.
Solo project with ~23K LOC of Perl and counting here. Bless you, Larry Wall and Perl maintainers. Keep it up!