The backwards incompatibility of Perl 6 absolutely killed Perl.
There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use because they still have momentum and lots of legacy things built in them. So being ugly or old isn’t enough of a factor for people to abandon something in droves.
Once you need to rewrite everything, there’s no reason to stay with something you know since you need to fully retool anyway.
As a Perl programmer since v5 was released, the confusion around 6 completely destroyed almost everyone’s enthusiasm, and immediately caused all new projects to avoid Perl. It seemed like 5 had reached the end of the line, and 6 was nowhere to be found. Nobody wants to gamble so many hours of their lives, and the future of their business, on such an uncertain environment.
If Perl 6 had any visible movement within the first few years, it might have survived, but it was a good decade before they even admitted Perl 6 might take longer than expected, and then more time after that before they admitted it should have been a new language. 6 was interesting for language geeks, and they probably did some cool things, but you can’t run a large popular project like it’s a small research project. That completely destroyed all momentum in the community. Perl 5 development only resumed far too late, after the writing was already on the wall.
Both Bill Gates and Linus understand backwards compatibility as a sacrosanct principle. Python only just barely survived the jump from 2 to 3. JavaScript can only survive this because there’s no other option in a browser.
> Python only just barely survived the jump from 2 to 3.
I really don't think this is true at all.
Python 2 to 3 took a really long time, it was a real struggle, lots of people stayed on 2 for a really long time.
But I really don't think Python was close to dying the same way Perl has/is. There was no risk of Python not "surviving" in my opinion.
There was always a clear way forward and people were actually moving. The mass migration of millions or billions of lines of code from 2 to 3 actually happened and has many high profile million+ line migrations, like Yelp or Dropbox.
There was never anything similar for Perl 5 to 6, totally different situation.
1. The data science / AI crowd that was gathering momentum any many only used Python 3.
2. No popular alternative. Perl got python as an alternative.
Python was also a good, simple language and had a good healthy culture. But it's nothing sort of a miracle that it survived that biblical software calamity.
I was not affected by Py3 at all. First I completely ignored it for five years while it gestated. Then started kicking the tires when 3.4 dropped on a LTS. When 3.6 with better dicts and f-strings landed I moved over with barely a whimper, since I'd had a decade to get things upgraded to 2.7 first.
None of my projects needed to worry much about char encoding, and I used logging extensively starting under 2.6 or so.
Python 2.7 was kept very much alive, with a number of small improvements from the 3.x branch backported to it.
Big players, like Django or SQLAlchemy, kept versions both for 2.x and 3.x for quite some time. This allowed for a smooth transition, when all of your dependencies finally had good versions for 3.x.
The difference between Python 2.x and Python 3.x was not dramatic. I would say it was mostly cosmetic up until 3.5 when async landed. Even with these small changes, the splitting of byte strings and character strings alone (an obvious move towards sanity) was plenty annoying for many projects.
Communities and ecosystems are fragile; sharp turns can easily break them.. Even careful maneuvering, like the Python 2 → 3 transition, put very visible strain on the community. A crazy jump that was Perl 6 was not survivable, even though Raku may be a fine language.
Long before the AI/data science breakout, we were noticing in our consulting practice (2016-2020) a sharp dropoff in Ruby at startups, and Python as the modal language (by the time I left in 2020, it would have gone Python -> Node -> Ruby).
So no, I don't think AI saved Python; it was fine before then.
I don't know. Isn't Python still viewed as a mess now? I was thinking of taking the time to learn it as the best way to write cross-platform utilities, but encountered a lot of negative sentiment about its ecosystem. And all the environment managers you seem to need for it are a turn-off.
Granted, this is coming from a relative noob who read and followed a couple of "how to set up Python properly" articles and that's about it. But I pretty much decided to spend my time on JavaScript, despite its cumbersomeness for implementing simple utilities.
You're contradicting yourself - if Python had no popular alternative, what would have new people used instead and what would existing code have migrated to?
Can you imagine if the PSF had been working on Python 4 in parallel, with more backwards compat shifts or even a radically modified syntax?
I think another saving grace was, when considering Python 3, one's choice was between "easy-ish migration to best in class" and "difficult rewrite into second-best". Meanwhile with Perl 5/6 it was "two moderately hard migrations into metastasized shell-script has-been language" and "difficult rewrite into best-in-class with lots of upside".
> There was always a clear way forward and people were actually moving.
I was always of the impression that people were very reluctant to move even though the benefits were clear and the movement not nearly as difficult as people claimed. But I still hear people complain about, for example, how you can't run CPython 2.x bytecode on a modern CPython runtime even though you can't run CPython 3.13 bytecode on a CPython 3.14 runtime, either and that hasn't slowed anyone down at all.
> the movement not nearly as difficult as people claimed.
Original was really rough because the core team had gone in the wrong direction on migration, and the Python io module was hell as well.
By 3.3-3.4 it was relatively smooth sailing but that took a lot of work from the community and core team both (reminder that Python 2.7 was released after 3.1, backporting a number of features to make compatibility easier, and old features were reintroduced as late as 3.5).
Python continued growing fast during the 2 to 3 transition, it was nowhere near dying. It was one reason it took so long, people were starting new Python 2 projects 5 years after Python 3 was released. Only around 2017/2018 the default for new projects kind of became Python 3.
Not to dispute the overall premise that Perl 6 did enormous damage to Perl, I want to interrogate this a little bit:
> There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use because they still have momentum and lots of legacy things built in them. So being ugly or old isn’t enough of a factor for people to abandon something in droves.
Nothing forced anyone to abandon Perl 5 code, and I suspect most Perl 5 wasn't abandoned for its own sake; it was a Cambrian explosion of new greenfield projects rising out of the ashes of Web 1.0 that brought Python and Ruby and PHP to the forefront. It's just that a lot of the Perl 5 code out there in the world was quick and dirty CGI scripts that died naturally after the dotcom crash and as the web became more sophisticated.
> it was a good decade before they even admitted Perl 6 might take longer than expected
I was there at OSCon when Larry announced Perl6, and that it would be "out by Christmas". And I was there the next year, when he was asked about that, and cheekily replied "well, we never specified _which_ Christmas."
You can break backwards compatibility, if you are careful.
In fact, Perl even had the tools to break backwards compatibility baked in from the v5 days.
I agree that Perl 6 is why perl died, but I think the thing that really killed it is what you mentioned. It was a completely different language that spend over a decade with a release date of "soon".
Who wants to work on a language that isn't being worked on because the next thing is AND where from what you know of the next thing everything will be a complete rewrite.
A completely different language, a decade of development to Perl 6, and Python eating its lunch in the meantime. Perl is often called a write only language, and there's Python with
for line in file:
If you were new to the field at that time, Python seemed like a no-brainer.
Even as an experienced developer who even owned CPAN modules and was very familiar with the Unix ways, Python was a no-brainer.
I mention this on light of the article's claim that this has to do with "a new generation of programmers brought up on … I don’t know, Microsoft systems, Visual Basic and Java". No. The new languages that appeared were just so much much better.
> The backwards incompatibility of Perl 6 absolutely killed Perl.
The insane lead time of Perl 6 to even get to a point of backwards incompatibility was it for me.
I'd started on an early version of perl 4 and went through the 5 transition and was excited about 6. For what seemed like "Duke Nukem Forever" time, and finally my fickleness drew me to other languages and frameworks.
There are also a lot of things about Perl that prevented new developers from choosing it when other options were available.
I learned Python from reading a pocket language reference that just described the syntax and standard library, because the language was simple and easy to understand and everything made sense.
Conversely, I was trying to debug a script someone else ran and came across a line that said '$|++'; it was impossible to search for on the web, and when I asked on IRC the only answer I got was 'man perldoc' which also did not answer my question in any reasonable way.
For anyone wondering: `$|` is an alias for `$OUTPUT_AUTOFLUSH`; it defaults to 0 (line-buffered) but any non-zero value means 'flush output immediately'. Thus '$|++' changes 0 to 1 (or 1 to 2, etc), which means that '$|++' means 'turn off output buffering'. No one could be bothered to say that; if you had questions about the language you clearly didn't RTFM well enough so that became the default/only answer I ever saw.
Meanwhile, the PHP community was often welcoming and helpful to newcomers, despite most of them being bad at programming and giving bad advice, and the Python community produced a language that was so often self-explanatory that new user questions were more about how Python did things or asking about how to implement things they didn't realize were in the standard library.
So yeah, lots of things contributed to Perl's decline, but the community being a bunch of elitist toxic dicks sure didn't help matters and it meant that as the set of people looking to learn how to do programming on Linux grew past the neckbeards looking for any metric to show that they were better than other people then Perl's growth potential was finite.
When I asked a question on the PERL Usenet group in the 90s, I used the word "newbie" to describe my skill level. I got an automated email explaining why I shouldn't use that word.
Sorry for the bad experience you had, I believe it's always better to be kind to strangers on those global nets. But TBH perldoc would really work very well for you.
> when I asked on IRC the only answer I got was 'man perldoc'
Your overall point notwithstanding, this was just bad advice. What you want is `man perlvar` (or equivalently `perldoc perlvar`) which documents this and other predefined variables:
HANDLE->autoflush( EXPR )
$OUTPUT_AUTOFLUSH
$| If set to nonzero, forces a flush right away and after every
write or print on the currently selected output channel.
Default is 0 (regardless of whether the channel is really
buffered by the system or not; $| tells you only whether you've
asked Perl explicitly to flush after each write). STDOUT will
typically be line buffered if output is to the terminal and
block buffered otherwise. Setting this variable is useful
primarily when you are outputting to a pipe or socket, such as
when you are running a Perl program under rsh and want to see
the output as it's happening. This has no effect on input
buffering. See "getc" in perlfunc for that. See "select" in
perlfunc on how to select the output channel. See also
IO::Handle.
Mnemonic: when you want your pipes to be piping hot
Also, `man perl` gives a great overview of the extensive number of Perl-related manpages. I think any person that starts from `man perl` will be able to answer a lot of their questions, but part of the problem was that around the millennium, people stopped reading man-pages, and started looking for information on the web. perl was one of those old-school tools that were documented extensively in man-pages, but past 1995 ~nobody bothered to read man-pages anymore.
That variable in particular gets covered in the Llama book as well. Anyone serious about learning perl in the 90's had at least one of the Camel or Llama books.
is too curt, and therefore may feel hostile especially for native English-speakers who are used for polite communication to be more wordy. But cultural things aside it's actually a good working solution.
Fair enough, but I think the first part of the advice would be a lot more helpful if it included the second part too. It's the intermediate step that turns people off: why do I need to learn about `perldoc` when I asked about `$|`? (And that's assuming the question asker is familiar with man-pages to begin with, otherwise, you need to read `man man` first!) It feels like you're sending them off on a wild goose chase, even if that's not your intent.
In the millennial web forum world, a n00b would ask "what does $| do?" and the answer would be "it disables output buffering", which is what the n00b wanted to know in the first place. It's the Stack Overflow model of giving men fish, instead of teaching them how to fish.
And in today's LLM-powered world that's only more true. If you ask ChatGPT "In a Perl script, what does $|++ do?" it will immediately give you a correct and concise answer, not make you read `man perldoc` first.
I agree in general (and already commented on this). But some people believe it's like giving fish instead of fishing rod. And I think it was prevalent idea in tech circles during 90s-00s that people who don't read that fm waste other participants time, and needlessly multiply forum topics or extend conversation history. Which was seen as uncivil behavior in those times.
The problem is with man pages themselves. You shouldn't have to read 100% of something to find 0.1% of something. In fact, this concept is covered extensively in CS theory about sorting. Reading a manpage is less efficient than asking someone who already knows.
Well, what Perl code is not real-world? And by ugly you mean what - not verbose or what? Something is ugly for ones, but nice to others. I doubt that really is a factor driving a demise of language, otherwise features like regexes would be non-existent today.
As a very long-time Perl developer and FOSS contributor, I think this blog post is incorrect about whether Perl 6/Raku was a factor in Perl's decline. I think Perl 6/Raku did a few things that hurt Perl 5:
1. It pulled away folks who would otherwise have spent time improving Perl 5 (either the core or via modules).
2. It discouraged significant changes to the Perl 5 language, since many people figured that it wasn't worth it with Perl 6 just around the corner.
3. It confused CTO/VP Eng types, some of whom thought that they shouldn't invest in Perl 5, since Perl 6 was coming soon. I've heard multiple people in the Perl community discuss hearing this directly from execs.
Of course, hindsight is 20/20 and all that.
Also, even if Perl 6 had never happened the way it did and instead we'd just had smaller evolutions of the language in major versions, I think usage would still have shrunk over time.
A lot of people just dislike Perl's weird syntax and behavior. Many of those people were in a position to teach undergrads, and they chose to use Python and Java.
And other languages have improved a lot or been created in the past 20+ years. Java has gotten way better, as has Python. JavaScript went from "terribly browser-only language" to "much less terrible run anywhere language" with a huge ecosystem. And Go came along and provided an aggressively mediocre but very usable strongly typed language with super-fast builds and easy deploys.
Edit: Also PHP was a huge factor in displacing Perl for the quick and dirty web app on hosted services. It was super easy to deploy and ran way faster than Perl without mod_perl. Using mod_perl generally wasn't possible on shared hosting, which was very common back in the days before everyone got their own VM.
All of those things would still have eaten some of Perl's lunch.
I think this is mostly the correct take. Perl's strength is that it was really good and quick and dirty one-offs, especially with text manipulation. This made it particularly popular with UNIX sysadmins and sometimes network admins. This was helped by the fact that CPAN made it easy to share a lot of these, which added to its popularity (it can't be overstated how revolutionary CPAN was).
The 1980s/1990s was full of many different data formats in a time before XML/JSON, often by long dead companies. Many a tech person was in a situation where "Oh fuck, how do I get this data out of some obscure database from some dead company from Boston that only ran on SCO UNIX into SAP/Oracle/etc" only to see somebody else already done it and made a CPAN module.
But stories like that became less common as DBs converged into a few players.
I would also say -- in the late 90s, Perl's claim to fame was that it had CPAN. At the time, CPAN was revolutionary: a big, centralized repo of open-source libraries, which you could install with a single command.
Now, of course, that's a common and maybe even expected thing for a library to have: Python has Pypi, Javascript has NPM, etc.
And the whole culture around CPAN, too, with the likes of Module::Build and Test::Harness and the strong expectations around POD documents. Nothing like that existed for the other scripting languages of the time.
There was a well-trodden path from writing a hacky one-off script to deal with a specific task, to realising "hey! this might be useful for others too!" and trying to make it a bit more generic, to checking in with your local Perl Mongers for advice, to turning it into a well-tested, well-documented CPAN module.
That was the route I followed as an early-career sysadmin in the dying days of the dotcom boom - it helped me take on much more of an "engineering" mindset, and was an important foundation for my later career.
I can't have written more than a few dozen lines of Perl in the last 15 years, but do I owe that community and culture a lot.
I was a Perl programmer from the early 1990s until into the 2000s and I mostly agree with you. It was a variety of factors.
The point where I disagree is I think Perl 6/Raku played a significant role in Perl's decline. It really gave me the perception that they were rudderless and that Perl probably had no future.
Other than that, I absolutely loved Perl. I love the language. It's super expressive. I never took a liking to CPAN. And I wonder if it could make a comeback given better dependency management.
I think Perl with tooling similar to uv would cause me to switch back today.
> The point where I disagree is I think Perl 6/Raku played a significant role in Perl's decline. It really gave me the perception that they were rudderless and that Perl probably had no future.
I assume you disagree with the blog post, not with my comment, since this is exactly what my comment says too!
My impression was experienced Perl programmers took pride in making the smallest code possible, all in one line.
At my company they really locked in the project being dead if the original contributors left.
Perl propped up regex (JavaScript regex is based off of it), so I get the impression Perl practitioners tried to make all the code regex-y as possible as a cultural thing.
Not to mention that trying to understand existing Perl by asking the community 'what does this do' or 'how does this work' often (in my experience) resulted in 'RTFM' or 'man perldoc' rather than someone taking any time to actually answer the question, whereas other communities were more welcoming and helpful to each other. That made it difficult to learn Perl through other people's code compared to other languages.
> Also, even if Perl 6 had never happened the way it did and instead we'd just had smaller evolutions of the language in major versions, I think usage would still have shrunk over time.
Maybe. I mean the whole point of 6 was to modernize perl.
Perl needed efforts like 6 to happen, but it needed them delivered in smaller chunks over the years rather than as a big decade long "And now 6 is here".
Java learned this lesson after Java 8 and 9 which took multi-year effort to deliver 1 or 2 big changes to the language and the JVM. Now Java has multiple efforts in flight which have trickled in over the years (tickling me as a dev). Every 6 month release is a little better which makes the multi-year efforts seem all that much more worth it when they land.
You mention it last, but I think PHP was most of it. PHP was the first and best-integrated technology for this world, which was huge and impactful. The "center of thought" in the text processing problem area moved hard to web development. And so the ideas about what needs to be improved or changed rapidly centered themselves around "Things PHP Did Badly". And that begat Ruby and Node, not a fixed-up Perl.
Perl remained (and remains!) eminently useful in its original domain of Unix system automation glue and ad-hoc text analysis. But it was denied a path to the future by PHP, and by the time PHP was itself replaced it was too late.
Finally everyone else (python in particular) sorta caught up to the "clever systems glue" feature set, and the world moved on entirely. Perl is mostly forgotten now except by those of us who lived it.
PERL tripped over it's own feet (too clever, line-noise, unmaintainable).
Java(TM) being "guaranteed to be business-like" sucked the serious use cases away.
PHP was easier to grok, had "editable man pages" (ie: comment forum attached to each built-in), and didn't have "slow CGI overhead" or "FastCGI complexity".
Python was waaaay easier to read/write/maintain, and was a serious alternative (except for trickier process-control integration, you couldn't just "$XYZ = `ls -al`" like you could in perl).
...and then "PERL6 will be gloriously filled with rainbows, butterflies, will be backwards incompatible, and will be released Any Day Now(tm)" sucked alll the oxygen out of a developer investing in perl.
By the time nodejs became another contender for server-side languages, there was no place for PERL as it's effectively become kindof a COBOL for unix systems. Don't touch it if you can avoid it, and it requires expensive, difficult-to-find specialists to maintain it if you need to.
By the time Perl 6 was around, Perl's lunch was already eaten by Python. Only a few table scraps left. Perl 6 would have had to be a better Perl 5 and a better Python 2 to win.
Python came with better batteries and better syntax. It allowed producing code you could read and understand a week later. Perl I found was a write-only language for me. I went back looking at my old Perl code and I couldn't decipher it without some effort.
And Python became popular not just because it was a better Perl, but it attracted folks who used Java and C++. CPU speeds were getting fast enough that you could actually do file and network IO at acceptable speeds without all the `public static void main(String[] args)` and `System.out.println(...)` boilerplate, but still had all the object oriented bits like inheritance and composition with which you could go crazy with if you wanted.
Personal anecdote in support: my first job out of college was at a data-analysis company, where my task was usually to write one-off scripts to extract data from various data sources and massage it into the format the analysts wanted for their spreadsheets. I wrote most of those scripts in Perl at first, with the odd Bash script here and there. Then one of my coworkers said "Hey, if you like Perl, you'll love Python". I learned Python (2.1 was the most recent version at the time, which tells you how old this story is) and almost immediately switched over. All my new one-off data-extraction scripts from then on were written in Python (though still with the odd Bash script here and there).
Perl exploded because it was the easiest, richest ecosystem available to plug into CGI and the web.
PHP & Ruby & Python then collectively covered the same waterfront whether you wanted “easy” or “fun” or “simple”.
And I would propose that PHP attracting the developer cohort who wanted “easy” and Ruby/Rails attracting the developer cohort who wanted “fun” were each individually more damaging to the Perl ecosystem than Python.
Agreed. In grad school, I used Perl to script running my benchmarks, post-process my data and generate pretty graphs for papers. It was all Perl 5 and gnuplot. Once I saw someone do the same thing with Python and matplotlib, I never looked back. I later actually started using Python professionally, as I believe lots of other people had similar epiphanies. And not just from Perl, but from different languages and domains.
I think the article's author is implicitly not considering that people who were around when Perl was popular, who were perfectly capable of "understanding" it, actively decided against it.
To me Perl was just Weird, to no particular end. Not the kind of mind expanding Haskell/Prolog/Lisp weirdness that opens up new possibilities. It just does roughly the same things as every other language, but everything is done slightly differently due to evolving out of the primordial soup of bourne shell and AWK filtered through Larry Wall's brain.
Perl and Python were similarly powerful and useful languages, but I could learn and start producing useful code in Python after reading an hour long tutorial. Perl took an order of magnitude longer, and remained more awkward to use just due to the Weirdness. There was a momentum building in the early 2000s toward competitors like Python and Ruby that were seen as less crufty and more modern.
Perl's developers seemed to agree, since they cooked up their own competitor to Perl, an entirely different language confusingly called Perl 6. The coexistence of Perl 5 and 6 made the Python 3 transition look like a cakewalk -- at least it would have save for Perl 6's almost entire failure to exist for over a decade after its inception. It produced lots of constantly churning specs and blog posts about register based virtual machines with native support for continuations or whatever, but no implementation of a language that anyone felt comfortable using for any real development. Meanwhile people kept using the ossifying Perl 5 for existing applications, and gradually transitioning away as they were replaced.
Also PHP overtook it for the "just FTP a script to $5 shared hosting and make a webapp" use case.
Before Perl, there was no scripting language that could do systems tasks except maybe shell and tcl, but that's shell is an extremely unpleasant programming experience and the performance is horrid, and tcl's string-based nature is just too weird.
Perl gives you something more like a real programming language and can do shell-like tasks and systems tasks very nicely. Compared to what came before, it is amazing.
But then Ruby and Python came along and checked the "real programming language" box even more firmly than Perl while retaining the shell/systems angle. Ruby and Python were better than Perl along exactly the same axis as the one on which Perl was better than Tcl and shell.
IMHO Python killed both Perl and Ruby. While Ruby is more alive than Perl it's nowhere near as popular as Python.
I like Perl and used it professionally for year and vaguely remember probably around 2010x relatively massive Python evangelism (lots of articles, conferences, lots of messages from Python adepts on forums e.t.c). One of talking points (no longer needed nowadays) was that Python is backed (sponsored) by Google so Python will be successful and you should not worry about it's future and also if you will choose Python you will be successful (as Google is).
In previous life, worked on large object-oriented Perl. There was a difference between good Perl and the Perl in messy scripts. Good Perl was nice to work in but required discipline to keep organized.
I wonder if there was an earlier point of Perl's demise. Perl 5 came out with flexible object-oriented features, but it took years for packages like Moose to come out and make it nice and usable.
Entire enterprises ran/still run on Business BASIC and Delphi code. Billion-dollar fortunes have been made on such code. Those languages are used for serious things all the time.
Good luck getting any two people to agree on a sharp line between programming language and scripting language. Perl seems to swap sides depending on the year people are arguing about it.
To get Perl to work with apache (the most used web server for a time), there were two options: the not-so-complicated cgi script which gets executed from scratch on every request, then there was mod_perl which required a lot of tinkering with apache configurations and writing your code in a different way.
Even with those two options, you can't just write some code in a page and execute it without some sort of itermediate code.
Thats why php became so popular, perl coders could pick it up in a day ($ and all) and all you have to do is write .php files to a server - with the bonus that you have a rudimentary templating system built-in to php.
I vividly remember the first time a friend showed me PHP in the late 90s. You're saying I can just write a script that generates HTML and throw it in /foo/index.php and that's the whole thing?
It's wild that right up until Rails got popular, we were writing code that served billions of requests off of homebrewed MVC-ish PHP frankenframeworks.
> mod_perl which required a lot of tinkering [...]
Here we used mod_perl all over the place and it was glorious. It did take understanding how it to use it - well, yes - same as the rest of perl (or apache for that matters). But it was so well integrated! I still miss it.
"Picking it up in one day" is not a criteria for professional deployements.
Perl died because the other languages are better. IMO, Perl was a quick solution to a need; but it has since been eclipsed by modern languages.
I was in college 1999-2003, I did PHP in an internship, and then later did some Perl in one of my classes.
Perl (in my college class) was so incomprehensible that I decided that I would avoid it. I've never applied to a job that uses Perl, and never responded to a recruiter that was looking for a Perl engineer. I've never had to use it at work, and fortunately I've never worked with anyone who wanted to use it.
I think it's best to think of Perl as a transition technology.
2. Ruby (on Rails) taking over the workhorse task of serving up dynamic content that Perl had owned before then
3. Python completely dominating the utilitarian scripting/programming world in nearly every niche
Why did this happen? I was a work-a-day developer working in Perl v5 when this transition occurred and from my perspective and recollection v6's meandering development cycle -- which didn't really address the issues of the broader Perl community was the primary choice. Perl 6 was developed in a way that didn't address the broad concerns of the Perl community, and expected people to make a wholesale switch to what was effectively an entirely new language anyways. It forced people to go out looking and what they found were either stronger solutions to specific domains (Ruby on Rails) or a nicer language than what was being proposed (Python).
Where Python really excelled at the time was that it looked and worked very much like the pseudocode that was going around at the time, and had an opinion about how you should write your code. Perl is wonderful to write in, but in many ways is too expressive and permissive and it resulted in an ungodly mess that could be hard to maintain. Perl 6 simply leaned into that problem rather than encouraging a cleaner approach.
I never liked Python much, but damn if I couldn't argue that I was much more productive with it than Perl in the end. Which was weird because when I was really hacking in Perl I could write code almost as fast as I could think giving a kind of illusion of productivity. But Python was easier to integrate into a coherent team development structure and actual productivity is more important than feels.
I miss working in Perl. But I knew it was really finally dead when I was giving tutorial classes to new bioinformaticists who were being given old Perl codebases to update and they were getting through school without learning the language.
I would say PHP instead of Ruby was the big hit on Perl for web. It sat nicely in Apache and made replacing old cgi-bin much easier. It also had the philosophy and syntax heavily inspired by Perl
Python was indeed the scripting replacement. I would say it won because of its philosophy on simplicity and explicitness. Perl v5 suffered heavily in complex projects because the language itself was too complex and often cryptic
Already in the very early millennium, jokes like “Perl is an explosion in an ASCII factory” were going around the computer-nerd community, while several publishers were putting out affordable and fun and engaging books to learn Python. No surprise that Perl quickly declined in popularity for scripting. It has been amusing to watch the continual waves of reawakened interest in awk, while Perl seems to remain perennially marginalized now.
The value proposition for AWK is very different from Perl. AWK is a tiny language that can be learned quickly, and it's ubiquitous: a hard requirement for even the most bare-bones POSIX environment. AWK is on your machine already; Perl may not be. If you have to install Perl, you could just as easily install any one of hundreds of alternative scripting languages.
AWK scripts don't have any kind of dependency management features, so they naturally lend themselves toward being freestanding and self-contained. Perl, on the other hand, has a massive package ecosystem with transitive dependencies and widely varied quality and design aesthetic, amplified by the baroque design of the language. AWK is as close as a language can be to immune to dependency hell.
When Perl was new, perhaps many people saw it as "a better AWK", but I suspect most of the newcomers to AWK today don't see it in relation to Perl at all.
For me, Awk is this awesome tool for quick and dirty 1-3 line scripts to transform textual information. I hardly use it, but when I do, it serves its purpose well. It's also relatively easy to read and understand.
I remember learning most of Awk from a long, single web page that appeared to come from one of the official authors.
What is dead may never die. Perl will live on in the few mostly weird places doing things other languages can only dream of. And that’s fine. Perl doesn’t need to win the race or update itself. It is good enough as it is. It’s the magic wand in the world full of electronics. Sure you can light the room with an electric PHP/Python lightbulb script. But Perl can summon a levitating glowing orb out of thin air with a single line of code.
It's been discussed before, but Python just seemed more straightforward to a lot of people. It had a built-in object oriented model as well when that was the rage instead of the weak default one and dozen modules on CPAN to do object oriented programming. There was generally one way to do something and that was easier to learn than TIMTOWTDI.
"There should be one-- and preferably only one --obvious way to do it."
It also came with batteries included, which really lowered the learning curve.
Perl was well known for being a pain to read months after you wrote it. Most Python code in those days was readable by people who did not even know Python.
When I started my job in 2010, I took a class at work on Perl. I had done some Perl years before and had grown sick of it, but I thought I was just doing it "wrong" so I thought the course would tell me how to code in Perl "properly".
Nope - I'd been doing it "right" all along. I just hated the language. At the end of the course, I told the instructor (a graybeard) that he should just use Python, and that one day I'd teach the Python course and he should attend. He scoffed at the notion: "Languages will come and go, but Perl will always prevail!"
I never did teach that course, but I bumped into him about 7 years later. He had completely (and willingly) abandoned Perl for Python, and was a big Python advocate.
One of Python’s killer features is how easy it is to find a Python library wrapping some native code library written in C or Fortran. Those used to be notoriously difficult to write for Perl.
I was writing a comment asking if it was really easier. Then I took a look at Cython. Yes, this looks easier than Perl's XS, which I have some experience with! There are ways to do something similar in Perl these days, notably https://metacpan.org/pod/FFI::Platypus. But these are relatively new (starting in the 2010s) compared to the history of Perl, and Cython goes back to the early 2000s.
Somewhere in the continuum from SWIG through XS and on to Platypus there are also the Inline modules these days. They allow one to put inline sections of other languages into Perl code the way many language tools used to allow one to inline assembly into C or Pascal code.
There are some of these modules for other languages than those listed here, a lot of them as high level as Perl (including Raku and even another Perl system for some reason).
True. For whatever reason, these never displaced XS. For wrapping C libraries in particular, it's not clear to me how much Inline::C helps with this. You're still stuck using a lot of Perl C API calls, AFAICT, which I think is the biggest challenge of using XS (I still have nightmares from trying to figure out where and when to add `sv2mortal` in my XS code).
One or two calls into a library with a simple C interface isn’t that bad with Inline. You just use Inline to handle the Perl to C to Perl part, and actually do the interfacing in the inline C. It’s a lot more mess if you’re doing complex things and bringing complex data structures back to Perl, or having Perl make a lot of intermediate decisions and doing a lot of round trips. So if you use Perl to get the data ready to pass in, pass it in, do all the work in C that you need the library for, then pass the results back to Perl once it’s not terrible.
I’ve tried not to get into XS, so I couldn’t really compare.
Using Inline::C with your own C code in places where Perl is too much overhead is certainly easier than wrapping a complex existing library with a lot of interactions across the boundary.
FFI::Platypus or something like it really is the way of the future though for existing C calling convention libraries in other languages.
Perl 4 was a great upgrade to bash as a scripting language.
Perl 5 added a bunch of complexity to remake Perl into a programming language.
It failed.
Perl 4 was a great scripting language whereas Perl 5 was a terrible programing language.
Perl 5 lost to the better (dynamic) programming languages and bash reclaimed the scripting title as Perl 4 was dead.
I think it is due to the fact that Perl has some confusing bits like those variable prefixes ($@%), the lack of function arguments (I know that this has changed recently), not really great error handling, etc and so people started using languages which seemed easier to use like Python.
The variable prefixes are just the tip of the iceberg. The real problem with those prefixes is that they, themselves, are context-dependent on attributes associated with the underlying data type at run time. So you can find yourself in a situation where the behavior of the syntax differs in ways that are difficult to control for during development.
Strongly agree. A language which has something like “wantarray” as a first-class feature is semantically…unique, at best, probably more like “flawed by design”. All the oddness with typing and sigls descends from that.
Same for autovivification. Insane feature. Useful for some problems but causes many more.
Which is a shame, because perl5 semantics had some nice features too! But there’s only so much you can do with a structure whose foundation is so wacky.
I remember trying to use the new "reference" feature (when it was new), with "blessing" and so on and so forth, to try to create real data structures, and finding in some way or another that it was just not regular. I can't recall the details, but something along the lines of a feeling that the syntax worked differently for, say, the top level of a tree (or first index of a multidimensional array, etc.) vs the rest of the structure.
Yep. Perl the first language I ever used to professionally do something approximating "real programming" (as opposed to one-off scripting). And then I learned Python and never touched Perl again ... at least at the time, to my very inexperienced self, it felt like an improvement on every single axis.
In retrospect, probably 90% of my enthusiasm for python over perl was just "if you use python, you never have to think about variable sigils ever again." That and `string.split()`.
Yes, that's almost as old as some currently-hyped programming languages. But it's quite new compared to the natural behaviour of some developers (a fact that I used to find surprising and now just find disappointing).
Comparably: today, in the Python world, people are praising tools like uv because now they "don't have to understand virtual environments". And continuously since the introduction of PEP 668 three years ago, people have been grumbling about the expectation to leave "externally managed environments" alone. But uv still uses virtual environments; and `venv` has been in the standard library since 2012, and the third-party `virtualenv` that it's based on has been available since 2007.
I learned and used Perl professionally from around 2005-2015 and experienced first-hand the ossification, fear of change, and lack of innovation in Perl 5 development. It seems all the talent and effort started being wasted on making Perl 6 the bestest, most elegant, most useful programming language in the world. Just seeing the neglect of Perl 5 kept me from ever considering Perl 6 and motivated me to move to other languages.
My experience of working with Perl as a primary language from late 90s to today: Perl was dead long before Perl 6/Raku was a real thing. By the time that happened it had already lost massive ground to PHP, Python, Java, etc.
PHP had replaced CGI as the easiest way to get code on a webserver, Python and Java were easier to read and understand, easier to structure large systems with, and generally easier to use. Ruby came along and MVC frameworks became the thing for complex web platforms.
Meanwhile Perl was sorta keeping up, the "Modern Perl" movement helped dispel myths about "write only" code, things like Moose, DBIC, Catalyst, Mojolicious, etc meant you could write pretty modern stuff with it. But the community was smaller, fractured by Perl 6 and dominated by some ahem divisive characters which made it intimidating for newcomers, and it just slowly died from there.
By the time Stack Overflow came along it was easy to see that other languages had vibrant communities surrounding them and for me it never really recovered.
I have great love for Perl, but I'm not super eager to go back to using it.
I used it in probably one of the more cursed contexts I've ever heard of. Understand[0] is a static analyzer for many languages, and one of its killer features is that it is programmable with a Perl API. I used this feature at a defense consulting job to help target audits of huge, multi-million LOC codebases.
Perl's expressivity was very useful here. I cut my teeth on functional programming concepts to write some very nice traversals. The runtime environment of the host program was a nightmare to deal with though.
I learned Perl back in the day. It was fun and powerful.
But I think the package management and culture killed it for me. People took pride is writing obnoxiously messy code. Package dependency hell. Gung ho borderline toxic RTFM culture.
Personally, back when Perl 6 was harmless vaporware, I never found a place for Perl 5.
For moderately advanced text processing with regular expressions, supposedly its strong point, it was far less elegant and concise than AWK at the low end and far less readable and less batteries-included than Python for more complex tasks involving some integration.
For dynamic web pages, another of the main uses of Perl, PHP was purposefully designed and (while not really good) practical and user-friendly, with plenty of other obviously more robust and serious options (Ruby, Java, later Python, etc.) for more enterprise projects.
It sounds like Perl just wasn't your style and that's okay.
But, Perl was immensely popular, particularly in the 1990s in its 4.x/5.x days. We used it because it was precisely more elegant, ergonomic and performant than awk :-)
Later on, Python gained more traction because it was more batteries-included, and PHP evolved from being a toy named "Personal Home Page".
Perl was immensely popular, but it isn't necessarily enough to qualify for the personal "bubble" of languages one learns.
It was a good choice of proven, general purpose interpreted scripting language for you in a time when Perl competed with AWK and shell scripts, but in the 1990s I used mainly C and C++ before adopting Java quite early and almost exclusively; when I later decided to learn some proven, general purpose interpreted scripting language Python was my obvious choice: more advanced than Perl 5 and more popular than Ruby.
I was a Perl programmer, and I looked down my nose at PHP. Silly me, then and now
Why did PHP, an objectively a worse language, win?
Rasmus Lerdorf said in a quote I can no longer find, it was modperl vs. modphp for Apache.
Modperl was, typically for Perl, very comprehensive and allowed access to all the Apache processing hooks
Modphp was, typically for PHP, just enough to speed up rendering so only allowed access to the barest minimal set of hooks
Modperl, so much better (I can hear myself say 30 years ago)
But at the time most websites, by count not by traffic, ran on shared hosts where the system administrator gave you access to software. If they installed mosdperl you would be able to intercept, read, and change traffic for all websites hosted on that machine
Modphp, not so.
So PHP was widely available to the pioneers in the day, people scratching together a little web hosting business and growing . Perl was not
Not enough on its own to kill Perl, but an important nail in its coffin
From a recruiter’s perspective, I remember recruiting full stack Perl people for a San Jose based tech company in 2010. I was able to secure one really good Perl guy who had just been laid off from Yahoo, but there just wasn’t anyone else who was relatively easy to find with the experience this company wanted. I was charging by the hour, and I distinctly remember suggesting that the company consider hiring non-Perl people and letting them learn on the job as I wasn’t going to be able to find what they wanted. They kept looking for Perl people and I kept charging them. I wasn’t shocked when an executive at the company eventually asked why the recruiting bill was so high given the lack of results.
I use shell, vim, sed all the time (awk less but i have used it). I've never used perl. I don't even know if i've ever even encountered a perl program that i wanted to look inside.
I think its just one of those things, they lost mindshare and people stopped making stuff in perl. Network effects made it snowball from there. How often do you see code examples written in perl? Almost never. I see people write blogs with code snippets in python, c, rust or even shell all the time. Never perl.
Momentum matters and perl lost it. I think of perl the same way i think of cobol or fortran.
Back in 1994, Perl was an amazing thing to me (as someone who was accustomed to mainframe scripting languages up to that point), and it helped make me very productive. But it sometimes would seem like the epitome of "Write once, read never". Tim Bray even remarked on its abstruseness back in 2003:
I still use perl. It's my go to for string parsing (think pipe log file, do something with it and send it to stdout). It's also my go to for anything that I still want to work in 10 years.
Perl is powerful, expressive, and cryptic. Its popularity faded during a time when the popular trend of programming languages was towards simplicity and legibility. C++ gave way to Java and C#.
Also, Perl's strength was text processing in a world where data was moving out of simple columnar text formats and into databases, xml, json, and other formats better represented by object models than lines of text.
Even before the Perl 6 insanity dropped, there was a serious underlying problem in the Perl ecosystem: CPAN. There was this module (I don't remember its name, or author) that was pretty important: you'd end up using it if you were serious about Perl.
One day, around 2000 or so, the author/maintainer, a well-known guy in the Perl community, updated the package with an incompatible API. If you used that package, you had to update your code. There was no backward compatibility, nothing. To make things worse, the README stated that it would AGAIN change API in the future, but he didn't know yet what the change would be.
I considered this disastrous maintainer behavior, as I'm sure anyone reasonable would. It was clear I had to stop using this package, and anything else this guy could get his claws on. But there really wasn't a massive outcry that I could see, nobody calling him out for this crap.
That's when I knew I had to stop writing code in Perl. I tried Ruby but found it unstable at that time. Next project I used Python, and never looked back.
I sometimes wonder how different things might have been if Perl had been the dominant scripting language at the time that ChatGPT, Codex, Claude Code and other tools like that became available.
Would Python have been able to compete, in a world where Perl could be readily comprehended by LLMs?
So, maybe what killed Perl was lack of VS Code forks and lack of being agentic.
Perl is what killed Perl. I have never had as many "tear my hair out at 4AM" debugging sessions as I have had with Perl, because I missed some weird character somewhere.
I love Perl. I think, though, that the crazy mix of sigils and braces/brackets to work with complex data structures was one of the main reasons.
Especially for the type of users were Perl had gained some ground in the past...data science, DNA related stuff, etc. Non programmers.
If you look at just about any other language and how you would pull data in and out of json yaml, manipulate individual elements, etc... the Perl is just hard to decipher if you don't have immediate recall of all the crazy syntax for dereferencing things.
What put perl out to pasture for me was lack of static types, nor any capability of adopting them. We were told to wait for Perl 6 for that, and well, we saw how that went. I'm told that disabling indirect object syntax gives Perl a fighting chance at static analysis, but that in the end it's still the case that only Perl can parse Perl.
As someone that was already working during the dotcom wave, Perl is a tool I would still reach for, given the problem I might trying to sort out, if on an UNIX like platform.
> Binary package managers that chase down dependencies on their own weren’t a thing until the early 2000s, I think?
UNIX package managers started to be made available during the 1990's.
I definitely had Debian installs pulling binary package dependencies automagically via apt-get in 1999, and I think similar with RedHat a year or so before that.
About a dozen years ago, I noticed that the young all seemed to know Python, and did not seem to know Perl. Given that they would be maintaining such code as I wrote and was worth keeping around, I moved to writing in Python. Now when I write Perl, I do silly things like forget semicolons.
Perl can be very well written. I deeply regret not encountering Perl Best Practices when it came out.
My personal reason was observing the huge amount of investments into Javascript and its infrastructure (by Google and others). After Node.js was released it was a rational bet to make that Javascript would dominate, both server and client side. As someone who often does both front end and back end, it felt good to move to Javascript. It's got to be said that keeping a "common" directory around with shared code for both front- and backend is still a PITA, but still better than most other alternatives.
Around 2010 I ditched Perl for PHP because I had been using PHP for web and could write the same systems scripts in PHP as I used to write in Perl. Sticking with one go-to language is easier on the brain.
It would literally just be Python (and probably some php and maybe even ruby) plus "Bash is good enough and more ubiquitous for the things you don't need all of Python for," no?
It's definitely more powerful and has less foot guns than bash, the problem is the stigma is worse than bash. You will face more scrutiny and possible derision from your colleagues for using Perl than bash. It's not just questioning your taste or style either, it's because of the fear they might have to one day maintain or try to understand your Perl.
I speak from some experience. Because I'm a 90s UNIX nerd, I quickly hacked up a a bunch of stuff in Perl maybe 6 years ago to solve some text processing tasks for a compliance audit. It worked well and got the job done within the time constraints. I actually got some kudos for getting our team out of a jam and doing grungy work people weren't keen to do. My teammates though, they lost no opportunity to dunk on the fact that it was done in Perl, and questioned my decision at every opportunity. I ended up rewriting the whole thing in Python for our next audit.
The opinion of coworkers is not a factor - but I have a friend who says that he has to relearn Perl every time he needs to use it. Do you have to use it every day to maintain fluency?
It doesn't take too long to get back into the swing of things. After a while, if you learn enough programming languages, they all tend to meld together in your brain, and the cost of switching isn't too disruptive. You know what you want to do, it's just the details that temporarily get in your way.
It’s strong as a better shell. Perl is even getting an increasingly good and complete default object model in the core language. One of the big complaints was always that the TIMTOWTDI included object libraries, of which there are many. Most of the popular ones are working on becoming wrappers around the new core one, and you can write new code directly with what’s in core.
I may blog about this next year, again[^1], as I'm working on a project that sort of covers it - not in a way that will answer the question but more observational.
Anyway, I feel Perl's popularity was hugely exaggerated in the mid to late 90s and early 00s. The alternatives were either not there in terms of language and toolchain features, ease of use, "whipuptitude" or whatever, or library support (CPAN was a killer app), or they were too old school or enterprisey. Sysadmins were using it everywhere so it got into all sorts of systems that other languages couldn't without much more faff.
Its back compatibility meant it stayed in those places for a long time. It's still in a lot of those places.
The fall in popularity the last decade or two was more of a regression to the mean, or perhaps below the mean. Many other languages have come along, which have contributed even more to the fall in share.
Yes, yes, Raku (né Perl 6) but I'd argue that also contributed to a lot of really good stuff on CPAN. The Perl 5 core did get neglected for a number of years, as @autarch says, which may have been a factor.
I heard a fascinating theory a few years ago on the decline of Perl:
In the early aughts, Google SRE recruiting had such a strong, selective focus on A-player sysadmins with Perl expertise that it drained the market of top talent. Within google these people began to adopt, and eventually create and evangelize newer, Googlier programming languages.
In other words, Perl expertise was the skills filter, and Perl itself a technological ancestor of certain modern languages like Go.
I worked at Booking.com for a year or so around 10 years or so, and most of their stack was in Perl. Folks there had mixed feelings about it, I'm not sure what things are like now, but I assume they're working to replace it.
Been using Perl since the beginning… essentially every time I needed to write a shell script more than 10 lines long I used Perl … eventually was also using it for web back end stuff too … kind of like duct tape. I still use it today if I need to write more than 10 lines of a bash script.
I was a happy perl user for a long time, probably until sometime in the early 2010s. I am a sysadmin and perl was a great tool for what I needed to do.
Jim Weirich was a heavy perl user for a long time, and we were both involved in the Cincinnati perl mongers group. He found ruby and fell in love. He thought Ruby would be a good fit for me and we had a long conversation about why he preferred it to perl. It took me a few years, but I eventually took his advice. As usual, Jim was right, and I haven't written any perl since then.
After twenty years of Perl, I switched to Python because I was encountering too many useful frameworks and systems that had no corresponding Perl packages. The last straw was when I wanted to use Mongo and found that the Perl package was unsupported.
I spent 10 years in perl and created a lot in it - it taught me a lot about code as a culture,importance of tests, TIMTOWTDI, etc. I think I owe a lot to it.
I found myself defending it more and more online against the folks who were nay sayers - those who complained about its syntax and it's quirks - but that wasn't a problem for unixers who used sed/awk/vim and all the other arcane tools. Perl wawa means to and end and it was the best tool to reach for (the glorious Swiss army knife).
I guess there was an infection period - the brain drain to python and Ruby meant it was harder to find decent quality libs on CPAN anymore as folks would only do things in python. And Yea, while CPAN is still rich, it's not the first hit on Google anymore.
Today, the map-sort-map Schwarzian transform is still the easiest to do in perl than any other language and it helps me whip up the throwaway scripts quick. Wouldn't change the language - I really love it!
In all seriousness mod_php killed Perl, or at least struck the fatal blow. In the late 90s I wanted to make dynamic web content, just simple CRUD stuff. The most reliable way to do this was Perl. As long as your hash bang and permissions were correct you could drop a script in a cgi-bin directory and it would work. It didn't matter if the server was Solaris, Linux, or some other Unix. Most hosts that supported Perl also at least had the CGI module installed as well.
It was worth fighting with Perl's syntax because it was the best option for web programming (for random amateurs like myself). Web hosts often didn't have C compilers available so C wasn't an option. TCL was workable but not as prevalent as Perl on web hosts. Same with PHP3. Keep in mind this was an era where you were deploying on machines you didn't on which you didn't have admin access. Most of the time you didn't have shell access on machines you'd deploy on.
As Linux adoption on servers exploded so did the deployment of PHP. It was easy to deploy PHP web apps since they could be readily dropped in your htdocs or public_html directory and be handled by the server. Enabling other CGI outside cgi-bin directories was uncommon.
So by 2000 or so there was no reason to learn Perl to do web stuff easily. You could do it in PHP which was already a templating language. The younger version of me that wanted to do web CRUD stuff bought a PHP book instead of a Perl book. With Python 2's release at that same time if you wanted to do portable non-web stuff you had a much nicer language than Perl available as well.
Perl was the internet in 1990s. People (me) who were doing unix systems work (C, shell, Perl and some DBs and FTPs) could now quickly throw a CGI script behind an Apache HTTP server, which tended to be up and running in many unixes :80 port back then (Digi, HP, Sun, etc). Suddenly I had a working app that would generate reports directly to people's browsers or full-blown apps on the internet! But Perl CGI did not scale at all (spawn 1 short-lived process per request will choke a unix fast), and even after mod_perl [1], that got quickly superseded by PHP, which was really built for the web (of the 1990s). Web frameworks and fastcgi arrived too late to Perl, so internet Perl was practically dead at the turn of the century.
The enterprise, who either did not have any webapps or had tried Perl CGI first and suffered it dearly, got pinged by their sales reps that Java and .NET (depending if you were a IBM, Sun or MS shop) were the way to go, and there they went with their patterns and anti-patterns for "scalable" million-dollar web stacks. That kicked-off the age of the famed application servers that resist up until today (Websphere, Weblogic, etc).
So Perl went back to being a glue language for stitching up data, C/C++ and shell, and that's how the 2000s went by. But by then, Ruby and Python had more sane communities and Ruby was exciting and Python was simpler - Perl folks were just too peculiar, funny and nerdy to be taken seriously by a slick new generation that coded fast and had startup aspirations of the "only $1B is cool" types. Also the Perl6 delusion was too distracting to make anyone event care about giving Perl5 some good love (the real perl keeping servers running worldwide), so by the 2010s Perl was shooting down to collective ostracism, even though it still runs extremely well, fast and reliably in production. By the 2020s the release cycles were improved after Perl6 became a truly separate project (Raku, renamed in 2019), the core has gone through a relative cleanup and finally got a few popular features in demand [3]. The stack and ecosystem is holding up fine, although CPAN probably needs some good tidying up.
The main issue with Perl at this point is that it has not been a target for any new stuff that comes out: any cool module, library, database, etc that is launched does not put out a Perl api or a simple example of any kind, so it's up to the Perl community to release and maintain apis and integrations to the popular stacks on its own, which is a losing game and ends up being the nail-in-the-coffin. By the way, nothing (OSS) that comes out today is even written in Perl. That reduces even further the appeal of learning Perl.
Strangely enough, lately Perl has seen a sudden rise in the TIOBE index [4] back into a quite respectable 9th position. TIOBE ranks search queries for X language and is not much of a indicator, being quite noisy and unreliable. My guess is that those queries are issued by AI agents/chats desperately scraping information so that it can answer questions and help humans code in a language that is not well-represented in the training datasets.
The backwards incompatibility of Perl 6 absolutely killed Perl.
There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use because they still have momentum and lots of legacy things built in them. So being ugly or old isn’t enough of a factor for people to abandon something in droves.
Once you need to rewrite everything, there’s no reason to stay with something you know since you need to fully retool anyway.
As a Perl programmer since v5 was released, the confusion around 6 completely destroyed almost everyone’s enthusiasm, and immediately caused all new projects to avoid Perl. It seemed like 5 had reached the end of the line, and 6 was nowhere to be found. Nobody wants to gamble so many hours of their lives, and the future of their business, on such an uncertain environment.
If Perl 6 had any visible movement within the first few years, it might have survived, but it was a good decade before they even admitted Perl 6 might take longer than expected, and then more time after that before they admitted it should have been a new language. 6 was interesting for language geeks, and they probably did some cool things, but you can’t run a large popular project like it’s a small research project. That completely destroyed all momentum in the community. Perl 5 development only resumed far too late, after the writing was already on the wall.
Both Bill Gates and Linus understand backwards compatibility as a sacrosanct principle. Python only just barely survived the jump from 2 to 3. JavaScript can only survive this because there’s no other option in a browser.
> Python only just barely survived the jump from 2 to 3.
I really don't think this is true at all.
Python 2 to 3 took a really long time, it was a real struggle, lots of people stayed on 2 for a really long time.
But I really don't think Python was close to dying the same way Perl has/is. There was no risk of Python not "surviving" in my opinion.
There was always a clear way forward and people were actually moving. The mass migration of millions or billions of lines of code from 2 to 3 actually happened and has many high profile million+ line migrations, like Yelp or Dropbox.
There was never anything similar for Perl 5 to 6, totally different situation.
> I really don't think Python was close to dying
It absolutely was. What saved it was:
1. The data science / AI crowd that was gathering momentum any many only used Python 3.
2. No popular alternative. Perl got python as an alternative.
Python was also a good, simple language and had a good healthy culture. But it's nothing sort of a miracle that it survived that biblical software calamity.
I was not affected by Py3 at all. First I completely ignored it for five years while it gestated. Then started kicking the tires when 3.4 dropped on a LTS. When 3.6 with better dicts and f-strings landed I moved over with barely a whimper, since I'd had a decade to get things upgraded to 2.7 first.
None of my projects needed to worry much about char encoding, and I used logging extensively starting under 2.6 or so.
Python 2.7 was kept very much alive, with a number of small improvements from the 3.x branch backported to it.
Big players, like Django or SQLAlchemy, kept versions both for 2.x and 3.x for quite some time. This allowed for a smooth transition, when all of your dependencies finally had good versions for 3.x.
The difference between Python 2.x and Python 3.x was not dramatic. I would say it was mostly cosmetic up until 3.5 when async landed. Even with these small changes, the splitting of byte strings and character strings alone (an obvious move towards sanity) was plenty annoying for many projects.
Communities and ecosystems are fragile; sharp turns can easily break them.. Even careful maneuvering, like the Python 2 → 3 transition, put very visible strain on the community. A crazy jump that was Perl 6 was not survivable, even though Raku may be a fine language.
Long before the AI/data science breakout, we were noticing in our consulting practice (2016-2020) a sharp dropoff in Ruby at startups, and Python as the modal language (by the time I left in 2020, it would have gone Python -> Node -> Ruby).
So no, I don't think AI saved Python; it was fine before then.
I don't know. Isn't Python still viewed as a mess now? I was thinking of taking the time to learn it as the best way to write cross-platform utilities, but encountered a lot of negative sentiment about its ecosystem. And all the environment managers you seem to need for it are a turn-off.
Granted, this is coming from a relative noob who read and followed a couple of "how to set up Python properly" articles and that's about it. But I pretty much decided to spend my time on JavaScript, despite its cumbersomeness for implementing simple utilities.
You're contradicting yourself - if Python had no popular alternative, what would have new people used instead and what would existing code have migrated to?
Can you imagine if the PSF had been working on Python 4 in parallel, with more backwards compat shifts or even a radically modified syntax?
I think another saving grace was, when considering Python 3, one's choice was between "easy-ish migration to best in class" and "difficult rewrite into second-best". Meanwhile with Perl 5/6 it was "two moderately hard migrations into metastasized shell-script has-been language" and "difficult rewrite into best-in-class with lots of upside".
> There was always a clear way forward and people were actually moving.
I was always of the impression that people were very reluctant to move even though the benefits were clear and the movement not nearly as difficult as people claimed. But I still hear people complain about, for example, how you can't run CPython 2.x bytecode on a modern CPython runtime even though you can't run CPython 3.13 bytecode on a CPython 3.14 runtime, either and that hasn't slowed anyone down at all.
> the movement not nearly as difficult as people claimed.
Original was really rough because the core team had gone in the wrong direction on migration, and the Python io module was hell as well.
By 3.3-3.4 it was relatively smooth sailing but that took a lot of work from the community and core team both (reminder that Python 2.7 was released after 3.1, backporting a number of features to make compatibility easier, and old features were reintroduced as late as 3.5).
I agree
If anything might have killed python it was not python 3 per se but shipping a "beta" version of Py3 as 3.0
Python 3 only got usable really around 3.3 or maybe 3.4
Python continued growing fast during the 2 to 3 transition, it was nowhere near dying. It was one reason it took so long, people were starting new Python 2 projects 5 years after Python 3 was released. Only around 2017/2018 the default for new projects kind of became Python 3.
Not to dispute the overall premise that Perl 6 did enormous damage to Perl, I want to interrogate this a little bit:
> There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use because they still have momentum and lots of legacy things built in them. So being ugly or old isn’t enough of a factor for people to abandon something in droves.
Nothing forced anyone to abandon Perl 5 code, and I suspect most Perl 5 wasn't abandoned for its own sake; it was a Cambrian explosion of new greenfield projects rising out of the ashes of Web 1.0 that brought Python and Ruby and PHP to the forefront. It's just that a lot of the Perl 5 code out there in the world was quick and dirty CGI scripts that died naturally after the dotcom crash and as the web became more sophisticated.
> it was a good decade before they even admitted Perl 6 might take longer than expected
I was there at OSCon when Larry announced Perl6, and that it would be "out by Christmas". And I was there the next year, when he was asked about that, and cheekily replied "well, we never specified _which_ Christmas."
You can break backwards compatibility, if you are careful.
In fact, Perl even had the tools to break backwards compatibility baked in from the v5 days.
I agree that Perl 6 is why perl died, but I think the thing that really killed it is what you mentioned. It was a completely different language that spend over a decade with a release date of "soon".
Who wants to work on a language that isn't being worked on because the next thing is AND where from what you know of the next thing everything will be a complete rewrite.
A completely different language, a decade of development to Perl 6, and Python eating its lunch in the meantime. Perl is often called a write only language, and there's Python with
If you were new to the field at that time, Python seemed like a no-brainer.Even as an experienced developer who even owned CPAN modules and was very familiar with the Unix ways, Python was a no-brainer.
I mention this on light of the article's claim that this has to do with "a new generation of programmers brought up on … I don’t know, Microsoft systems, Visual Basic and Java". No. The new languages that appeared were just so much much better.
> JavaScript can only survive this because there’s no other option in a browser.
JS 100% respects compatibility, they even avoided some methods because some popular libraries in the past used to extend the Prototype for arrays
> The backwards incompatibility of Perl 6 absolutely killed Perl.
The insane lead time of Perl 6 to even get to a point of backwards incompatibility was it for me.
I'd started on an early version of perl 4 and went through the 5 transition and was excited about 6. For what seemed like "Duke Nukem Forever" time, and finally my fickleness drew me to other languages and frameworks.
What we can learn is: evolution is a better choice over revolution given that there's no extreme internal or external pressure.
You can co-exist. That's the best path forward for breaks IMO.
Rust does this with "editions". That's where they can make breaks to the language. 2021 can still call 2017 edition code.
Perl actually had this as well with Perl 5. You could specify the version of the perl file and work from there.
Why they didn't do that with 6 was entirely bizarre. They basically promised to throw out all of CPAN with the next perl version.
There are also a lot of things about Perl that prevented new developers from choosing it when other options were available.
I learned Python from reading a pocket language reference that just described the syntax and standard library, because the language was simple and easy to understand and everything made sense.
Conversely, I was trying to debug a script someone else ran and came across a line that said '$|++'; it was impossible to search for on the web, and when I asked on IRC the only answer I got was 'man perldoc' which also did not answer my question in any reasonable way.
For anyone wondering: `$|` is an alias for `$OUTPUT_AUTOFLUSH`; it defaults to 0 (line-buffered) but any non-zero value means 'flush output immediately'. Thus '$|++' changes 0 to 1 (or 1 to 2, etc), which means that '$|++' means 'turn off output buffering'. No one could be bothered to say that; if you had questions about the language you clearly didn't RTFM well enough so that became the default/only answer I ever saw.
Meanwhile, the PHP community was often welcoming and helpful to newcomers, despite most of them being bad at programming and giving bad advice, and the Python community produced a language that was so often self-explanatory that new user questions were more about how Python did things or asking about how to implement things they didn't realize were in the standard library.
So yeah, lots of things contributed to Perl's decline, but the community being a bunch of elitist toxic dicks sure didn't help matters and it meant that as the set of people looking to learn how to do programming on Linux grew past the neckbeards looking for any metric to show that they were better than other people then Perl's growth potential was finite.
> the only answer I got was 'man perldoc'
When I asked a question on the PERL Usenet group in the 90s, I used the word "newbie" to describe my skill level. I got an automated email explaining why I shouldn't use that word.
Sorry for the bad experience you had, I believe it's always better to be kind to strangers on those global nets. But TBH perldoc would really work very well for you.
> when I asked on IRC the only answer I got was 'man perldoc'
Your overall point notwithstanding, this was just bad advice. What you want is `man perlvar` (or equivalently `perldoc perlvar`) which documents this and other predefined variables:
Also, `man perl` gives a great overview of the extensive number of Perl-related manpages. I think any person that starts from `man perl` will be able to answer a lot of their questions, but part of the problem was that around the millennium, people stopped reading man-pages, and started looking for information on the web. perl was one of those old-school tools that were documented extensively in man-pages, but past 1995 ~nobody bothered to read man-pages anymore.That variable in particular gets covered in the Llama book as well. Anyone serious about learning perl in the 90's had at least one of the Camel or Llama books.
Golly
There, the problem illustrated
"You are not serrious" is a downright hostile attitude
"man perldoc" as an answer can be translated as "f*^&%k off you stupid...."
Well, I was kind of just ruminating (ha) on how we learned in the past, but you in particular can certainly f*^&%k right off.
Let me respectfully disagree.
would tell one needs to use -v key to learn about a var. And consequently would tell everything one needs to know about $|So it was actually reasonable advice.
Fair enough, but I think the first part of the advice would be a lot more helpful if it included the second part too. It's the intermediate step that turns people off: why do I need to learn about `perldoc` when I asked about `$|`? (And that's assuming the question asker is familiar with man-pages to begin with, otherwise, you need to read `man man` first!) It feels like you're sending them off on a wild goose chase, even if that's not your intent.
In the millennial web forum world, a n00b would ask "what does $| do?" and the answer would be "it disables output buffering", which is what the n00b wanted to know in the first place. It's the Stack Overflow model of giving men fish, instead of teaching them how to fish.
And in today's LLM-powered world that's only more true. If you ask ChatGPT "In a Perl script, what does $|++ do?" it will immediately give you a correct and concise answer, not make you read `man perldoc` first.
RTFM might be reasonable advice, but its not "welcoming" advice.
I agree in general (and already commented on this). But some people believe it's like giving fish instead of fishing rod. And I think it was prevalent idea in tech circles during 90s-00s that people who don't read that fm waste other participants time, and needlessly multiply forum topics or extend conversation history. Which was seen as uncivil behavior in those times.
This comment kind of epitomizes the way the Perl community works, to be honest.
The problem is with man pages themselves. You shouldn't have to read 100% of something to find 0.1% of something. In fact, this concept is covered extensively in CS theory about sorting. Reading a manpage is less efficient than asking someone who already knows.
> There are many languages still in use today that have all kinds of warts and ugliness,
Right, but there aren't many with the kind of ugliness associated with real-world Perl code.
Well, what Perl code is not real-world? And by ugly you mean what - not verbose or what? Something is ugly for ones, but nice to others. I doubt that really is a factor driving a demise of language, otherwise features like regexes would be non-existent today.
All of rsync.net and "Oh By"[1] are coded in perl.
Which is to say, the customer facing web interface, ordering, management and our own management back ends.
Obviously the actual storage component employs no interpreters of any kind.
Alive and well!
[1] https://0x.co
As a very long-time Perl developer and FOSS contributor, I think this blog post is incorrect about whether Perl 6/Raku was a factor in Perl's decline. I think Perl 6/Raku did a few things that hurt Perl 5:
1. It pulled away folks who would otherwise have spent time improving Perl 5 (either the core or via modules).
2. It discouraged significant changes to the Perl 5 language, since many people figured that it wasn't worth it with Perl 6 just around the corner.
3. It confused CTO/VP Eng types, some of whom thought that they shouldn't invest in Perl 5, since Perl 6 was coming soon. I've heard multiple people in the Perl community discuss hearing this directly from execs.
Of course, hindsight is 20/20 and all that.
Also, even if Perl 6 had never happened the way it did and instead we'd just had smaller evolutions of the language in major versions, I think usage would still have shrunk over time.
A lot of people just dislike Perl's weird syntax and behavior. Many of those people were in a position to teach undergrads, and they chose to use Python and Java.
And other languages have improved a lot or been created in the past 20+ years. Java has gotten way better, as has Python. JavaScript went from "terribly browser-only language" to "much less terrible run anywhere language" with a huge ecosystem. And Go came along and provided an aggressively mediocre but very usable strongly typed language with super-fast builds and easy deploys.
Edit: Also PHP was a huge factor in displacing Perl for the quick and dirty web app on hosted services. It was super easy to deploy and ran way faster than Perl without mod_perl. Using mod_perl generally wasn't possible on shared hosting, which was very common back in the days before everyone got their own VM.
All of those things would still have eaten some of Perl's lunch.
I think this is mostly the correct take. Perl's strength is that it was really good and quick and dirty one-offs, especially with text manipulation. This made it particularly popular with UNIX sysadmins and sometimes network admins. This was helped by the fact that CPAN made it easy to share a lot of these, which added to its popularity (it can't be overstated how revolutionary CPAN was).
The 1980s/1990s was full of many different data formats in a time before XML/JSON, often by long dead companies. Many a tech person was in a situation where "Oh fuck, how do I get this data out of some obscure database from some dead company from Boston that only ran on SCO UNIX into SAP/Oracle/etc" only to see somebody else already done it and made a CPAN module.
But stories like that became less common as DBs converged into a few players.
> quick and dirty one-offs,
Then used for huge GUI apps that run slow like a wet week, unreliably
The same thing is happening with Python.
I would also say -- in the late 90s, Perl's claim to fame was that it had CPAN. At the time, CPAN was revolutionary: a big, centralized repo of open-source libraries, which you could install with a single command.
Now, of course, that's a common and maybe even expected thing for a library to have: Python has Pypi, Javascript has NPM, etc.
And the whole culture around CPAN, too, with the likes of Module::Build and Test::Harness and the strong expectations around POD documents. Nothing like that existed for the other scripting languages of the time.
There was a well-trodden path from writing a hacky one-off script to deal with a specific task, to realising "hey! this might be useful for others too!" and trying to make it a bit more generic, to checking in with your local Perl Mongers for advice, to turning it into a well-tested, well-documented CPAN module.
That was the route I followed as an early-career sysadmin in the dying days of the dotcom boom - it helped me take on much more of an "engineering" mindset, and was an important foundation for my later career.
I can't have written more than a few dozen lines of Perl in the last 15 years, but do I owe that community and culture a lot.
I was a Perl programmer from the early 1990s until into the 2000s and I mostly agree with you. It was a variety of factors.
The point where I disagree is I think Perl 6/Raku played a significant role in Perl's decline. It really gave me the perception that they were rudderless and that Perl probably had no future.
Other than that, I absolutely loved Perl. I love the language. It's super expressive. I never took a liking to CPAN. And I wonder if it could make a comeback given better dependency management.
I think Perl with tooling similar to uv would cause me to switch back today.
> The point where I disagree is I think Perl 6/Raku played a significant role in Perl's decline. It really gave me the perception that they were rudderless and that Perl probably had no future.
I assume you disagree with the blog post, not with my comment, since this is exactly what my comment says too!
> A lot of people just dislike Perl's weird syntax and behavior.
As much as I liked Perl back in the day, it did sometimes earn its reputation as a write-only language!
My impression was experienced Perl programmers took pride in making the smallest code possible, all in one line.
At my company they really locked in the project being dead if the original contributors left.
Perl propped up regex (JavaScript regex is based off of it), so I get the impression Perl practitioners tried to make all the code regex-y as possible as a cultural thing.
Not to mention that trying to understand existing Perl by asking the community 'what does this do' or 'how does this work' often (in my experience) resulted in 'RTFM' or 'man perldoc' rather than someone taking any time to actually answer the question, whereas other communities were more welcoming and helpful to each other. That made it difficult to learn Perl through other people's code compared to other languages.
> Also, even if Perl 6 had never happened the way it did and instead we'd just had smaller evolutions of the language in major versions, I think usage would still have shrunk over time.
Maybe. I mean the whole point of 6 was to modernize perl.
Perl needed efforts like 6 to happen, but it needed them delivered in smaller chunks over the years rather than as a big decade long "And now 6 is here".
Java learned this lesson after Java 8 and 9 which took multi-year effort to deliver 1 or 2 big changes to the language and the JVM. Now Java has multiple efforts in flight which have trickled in over the years (tickling me as a dev). Every 6 month release is a little better which makes the multi-year efforts seem all that much more worth it when they land.
All good points. There was a solid talk on modern web dev with Perl at the Carolina Code Conference last year.
Created some interest in several people who talked to me about experimenting with it for a while afterwards.
https://youtu.be/ommhbiRx-vI?si=qwkdU1Wo7uVBVse9
You mention it last, but I think PHP was most of it. PHP was the first and best-integrated technology for this world, which was huge and impactful. The "center of thought" in the text processing problem area moved hard to web development. And so the ideas about what needs to be improved or changed rapidly centered themselves around "Things PHP Did Badly". And that begat Ruby and Node, not a fixed-up Perl.
Perl remained (and remains!) eminently useful in its original domain of Unix system automation glue and ad-hoc text analysis. But it was denied a path to the future by PHP, and by the time PHP was itself replaced it was too late.
Finally everyone else (python in particular) sorta caught up to the "clever systems glue" feature set, and the world moved on entirely. Perl is mostly forgotten now except by those of us who lived it.
Great point! Confluence of simultaneous factors.
PERL tripped over it's own feet (too clever, line-noise, unmaintainable).
Java(TM) being "guaranteed to be business-like" sucked the serious use cases away.
PHP was easier to grok, had "editable man pages" (ie: comment forum attached to each built-in), and didn't have "slow CGI overhead" or "FastCGI complexity".
Python was waaaay easier to read/write/maintain, and was a serious alternative (except for trickier process-control integration, you couldn't just "$XYZ = `ls -al`" like you could in perl).
...and then "PERL6 will be gloriously filled with rainbows, butterflies, will be backwards incompatible, and will be released Any Day Now(tm)" sucked alll the oxygen out of a developer investing in perl.
By the time nodejs became another contender for server-side languages, there was no place for PERL as it's effectively become kindof a COBOL for unix systems. Don't touch it if you can avoid it, and it requires expensive, difficult-to-find specialists to maintain it if you need to.
Python killed Perl.
By the time Perl 6 was around, Perl's lunch was already eaten by Python. Only a few table scraps left. Perl 6 would have had to be a better Perl 5 and a better Python 2 to win.
Python came with better batteries and better syntax. It allowed producing code you could read and understand a week later. Perl I found was a write-only language for me. I went back looking at my old Perl code and I couldn't decipher it without some effort.
And Python became popular not just because it was a better Perl, but it attracted folks who used Java and C++. CPU speeds were getting fast enough that you could actually do file and network IO at acceptable speeds without all the `public static void main(String[] args)` and `System.out.println(...)` boilerplate, but still had all the object oriented bits like inheritance and composition with which you could go crazy with if you wanted.
Personal anecdote in support: my first job out of college was at a data-analysis company, where my task was usually to write one-off scripts to extract data from various data sources and massage it into the format the analysts wanted for their spreadsheets. I wrote most of those scripts in Perl at first, with the odd Bash script here and there. Then one of my coworkers said "Hey, if you like Perl, you'll love Python". I learned Python (2.1 was the most recent version at the time, which tells you how old this story is) and almost immediately switched over. All my new one-off data-extraction scripts from then on were written in Python (though still with the odd Bash script here and there).
I would bet against this hypothesis.
Perl exploded because it was the easiest, richest ecosystem available to plug into CGI and the web.
PHP & Ruby & Python then collectively covered the same waterfront whether you wanted “easy” or “fun” or “simple”.
And I would propose that PHP attracting the developer cohort who wanted “easy” and Ruby/Rails attracting the developer cohort who wanted “fun” were each individually more damaging to the Perl ecosystem than Python.
Agreed. In grad school, I used Perl to script running my benchmarks, post-process my data and generate pretty graphs for papers. It was all Perl 5 and gnuplot. Once I saw someone do the same thing with Python and matplotlib, I never looked back. I later actually started using Python professionally, as I believe lots of other people had similar epiphanies. And not just from Perl, but from different languages and domains.
I think the article's author is implicitly not considering that people who were around when Perl was popular, who were perfectly capable of "understanding" it, actively decided against it.
> By the time Perl 6 was around...
Just my opinion, but this says more about perl 6's insane development schedule than python's advantages.
PHP also contributed. Perl CGIs were a very popular way to build early web apps.
To me Perl was just Weird, to no particular end. Not the kind of mind expanding Haskell/Prolog/Lisp weirdness that opens up new possibilities. It just does roughly the same things as every other language, but everything is done slightly differently due to evolving out of the primordial soup of bourne shell and AWK filtered through Larry Wall's brain.
Perl and Python were similarly powerful and useful languages, but I could learn and start producing useful code in Python after reading an hour long tutorial. Perl took an order of magnitude longer, and remained more awkward to use just due to the Weirdness. There was a momentum building in the early 2000s toward competitors like Python and Ruby that were seen as less crufty and more modern.
Perl's developers seemed to agree, since they cooked up their own competitor to Perl, an entirely different language confusingly called Perl 6. The coexistence of Perl 5 and 6 made the Python 3 transition look like a cakewalk -- at least it would have save for Perl 6's almost entire failure to exist for over a decade after its inception. It produced lots of constantly churning specs and blog posts about register based virtual machines with native support for continuations or whatever, but no implementation of a language that anyone felt comfortable using for any real development. Meanwhile people kept using the ossifying Perl 5 for existing applications, and gradually transitioning away as they were replaced.
Also PHP overtook it for the "just FTP a script to $5 shared hosting and make a webapp" use case.
Python and Ruby killed Perl.
Before Perl, there was no scripting language that could do systems tasks except maybe shell and tcl, but that's shell is an extremely unpleasant programming experience and the performance is horrid, and tcl's string-based nature is just too weird.
Perl gives you something more like a real programming language and can do shell-like tasks and systems tasks very nicely. Compared to what came before, it is amazing.
But then Ruby and Python came along and checked the "real programming language" box even more firmly than Perl while retaining the shell/systems angle. Ruby and Python were better than Perl along exactly the same axis as the one on which Perl was better than Tcl and shell.
IMHO Python killed both Perl and Ruby. While Ruby is more alive than Perl it's nowhere near as popular as Python.
I like Perl and used it professionally for year and vaguely remember probably around 2010x relatively massive Python evangelism (lots of articles, conferences, lots of messages from Python adepts on forums e.t.c). One of talking points (no longer needed nowadays) was that Python is backed (sponsored) by Google so Python will be successful and you should not worry about it's future and also if you will choose Python you will be successful (as Google is).
> and tcl's string-based nature is just too weird.
TCL had the ability dynamically load and call into .so’s which was really powerful. Those who knew, knew.
Yeah tcl is awesome.
It's both awesome and weird.
Some people use it effectively to this day. Most either have no idea about it, or know about it but can't get into the mindset (like me).
> "Perl gives you something more like a real programming language ..."
It is a real general-purpose programming language, not a "scripting" language. Did you ever have a look at it?
In previous life, worked on large object-oriented Perl. There was a difference between good Perl and the Perl in messy scripts. Good Perl was nice to work in but required discipline to keep organized.
I wonder if there was an earlier point of Perl's demise. Perl 5 came out with flexible object-oriented features, but it took years for packages like Moose to come out and make it nice and usable.
BASIC and Pascal are real general-purpose programming languages as well, but I don't know anyone who uses them for anything serious.
Entire enterprises ran/still run on Business BASIC and Delphi code. Billion-dollar fortunes have been made on such code. Those languages are used for serious things all the time.
I’ve shipped Perl code so yeah, I have
That's a difference without a distinction
For many people especially old timer sysadmins, anything interpreted at runtime is a script.
TBH, prior to perl6, perl was such a horrid inconsistent mess, it reeked of shell.
Good luck getting any two people to agree on a sharp line between programming language and scripting language. Perl seems to swap sides depending on the year people are arguing about it.
In my experience those can't discern what's what are usually the ones who mainly did a bit of dabbling in either.
Assuming you've done more than dabbling, what's specifically the difference to you then?
To get Perl to work with apache (the most used web server for a time), there were two options: the not-so-complicated cgi script which gets executed from scratch on every request, then there was mod_perl which required a lot of tinkering with apache configurations and writing your code in a different way.
Even with those two options, you can't just write some code in a page and execute it without some sort of itermediate code.
Thats why php became so popular, perl coders could pick it up in a day ($ and all) and all you have to do is write .php files to a server - with the bonus that you have a rudimentary templating system built-in to php.
There really isn't much more to it than that.
I vividly remember the first time a friend showed me PHP in the late 90s. You're saying I can just write a script that generates HTML and throw it in /foo/index.php and that's the whole thing?
It's wild that right up until Rails got popular, we were writing code that served billions of requests off of homebrewed MVC-ish PHP frankenframeworks.
> mod_perl which required a lot of tinkering [...]
Here we used mod_perl all over the place and it was glorious. It did take understanding how it to use it - well, yes - same as the rest of perl (or apache for that matters). But it was so well integrated! I still miss it.
"Picking it up in one day" is not a criteria for professional deployements.
This is why I preferred Mike Migurski’s nickname for PHP: Apachescript; easy to integrate to the web server and next fastest thing to C for Apache.
I had to do a double take when I learned that modern cloud services still support PHP.
Mentally, I put it in the same bucket as legacy ASP, which is looooong dead.
Perl died because the other languages are better. IMO, Perl was a quick solution to a need; but it has since been eclipsed by modern languages.
I was in college 1999-2003, I did PHP in an internship, and then later did some Perl in one of my classes.
Perl (in my college class) was so incomprehensible that I decided that I would avoid it. I've never applied to a job that uses Perl, and never responded to a recruiter that was looking for a Perl engineer. I've never had to use it at work, and fortunately I've never worked with anyone who wanted to use it.
I think it's best to think of Perl as a transition technology.
Perl "died" through a 1,2,3 knockout of
1. failing to have a coherent path to Perl 6
2. Ruby (on Rails) taking over the workhorse task of serving up dynamic content that Perl had owned before then
3. Python completely dominating the utilitarian scripting/programming world in nearly every niche
Why did this happen? I was a work-a-day developer working in Perl v5 when this transition occurred and from my perspective and recollection v6's meandering development cycle -- which didn't really address the issues of the broader Perl community was the primary choice. Perl 6 was developed in a way that didn't address the broad concerns of the Perl community, and expected people to make a wholesale switch to what was effectively an entirely new language anyways. It forced people to go out looking and what they found were either stronger solutions to specific domains (Ruby on Rails) or a nicer language than what was being proposed (Python).
Where Python really excelled at the time was that it looked and worked very much like the pseudocode that was going around at the time, and had an opinion about how you should write your code. Perl is wonderful to write in, but in many ways is too expressive and permissive and it resulted in an ungodly mess that could be hard to maintain. Perl 6 simply leaned into that problem rather than encouraging a cleaner approach.
I never liked Python much, but damn if I couldn't argue that I was much more productive with it than Perl in the end. Which was weird because when I was really hacking in Perl I could write code almost as fast as I could think giving a kind of illusion of productivity. But Python was easier to integrate into a coherent team development structure and actual productivity is more important than feels.
I miss working in Perl. But I knew it was really finally dead when I was giving tutorial classes to new bioinformaticists who were being given old Perl codebases to update and they were getting through school without learning the language.
I would say PHP instead of Ruby was the big hit on Perl for web. It sat nicely in Apache and made replacing old cgi-bin much easier. It also had the philosophy and syntax heavily inspired by Perl
Python was indeed the scripting replacement. I would say it won because of its philosophy on simplicity and explicitness. Perl v5 suffered heavily in complex projects because the language itself was too complex and often cryptic
Already in the very early millennium, jokes like “Perl is an explosion in an ASCII factory” were going around the computer-nerd community, while several publishers were putting out affordable and fun and engaging books to learn Python. No surprise that Perl quickly declined in popularity for scripting. It has been amusing to watch the continual waves of reawakened interest in awk, while Perl seems to remain perennially marginalized now.
The value proposition for AWK is very different from Perl. AWK is a tiny language that can be learned quickly, and it's ubiquitous: a hard requirement for even the most bare-bones POSIX environment. AWK is on your machine already; Perl may not be. If you have to install Perl, you could just as easily install any one of hundreds of alternative scripting languages.
AWK scripts don't have any kind of dependency management features, so they naturally lend themselves toward being freestanding and self-contained. Perl, on the other hand, has a massive package ecosystem with transitive dependencies and widely varied quality and design aesthetic, amplified by the baroque design of the language. AWK is as close as a language can be to immune to dependency hell.
When Perl was new, perhaps many people saw it as "a better AWK", but I suspect most of the newcomers to AWK today don't see it in relation to Perl at all.
For me, Awk is this awesome tool for quick and dirty 1-3 line scripts to transform textual information. I hardly use it, but when I do, it serves its purpose well. It's also relatively easy to read and understand.
I remember learning most of Awk from a long, single web page that appeared to come from one of the official authors.
What is dead may never die. Perl will live on in the few mostly weird places doing things other languages can only dream of. And that’s fine. Perl doesn’t need to win the race or update itself. It is good enough as it is. It’s the magic wand in the world full of electronics. Sure you can light the room with an electric PHP/Python lightbulb script. But Perl can summon a levitating glowing orb out of thin air with a single line of code.
It's been discussed before, but Python just seemed more straightforward to a lot of people. It had a built-in object oriented model as well when that was the rage instead of the weak default one and dozen modules on CPAN to do object oriented programming. There was generally one way to do something and that was easier to learn than TIMTOWTDI.
Yes, the answer is Python, Python, Python.
There's a reason the Zen of Python includes this:
"There should be one-- and preferably only one --obvious way to do it."
It also came with batteries included, which really lowered the learning curve.
Perl was well known for being a pain to read months after you wrote it. Most Python code in those days was readable by people who did not even know Python.
When I started my job in 2010, I took a class at work on Perl. I had done some Perl years before and had grown sick of it, but I thought I was just doing it "wrong" so I thought the course would tell me how to code in Perl "properly".
Nope - I'd been doing it "right" all along. I just hated the language. At the end of the course, I told the instructor (a graybeard) that he should just use Python, and that one day I'd teach the Python course and he should attend. He scoffed at the notion: "Languages will come and go, but Perl will always prevail!"
I never did teach that course, but I bumped into him about 7 years later. He had completely (and willingly) abandoned Perl for Python, and was a big Python advocate.
if only python stuck to any of those ideals
Python has grown some warts, but I can still read code I wrote 20 years ago.
People who don't know Python will have a harder time reading modern Python, though.
One of Python’s killer features is how easy it is to find a Python library wrapping some native code library written in C or Fortran. Those used to be notoriously difficult to write for Perl.
I was writing a comment asking if it was really easier. Then I took a look at Cython. Yes, this looks easier than Perl's XS, which I have some experience with! There are ways to do something similar in Perl these days, notably https://metacpan.org/pod/FFI::Platypus. But these are relatively new (starting in the 2010s) compared to the history of Perl, and Cython goes back to the early 2000s.
Somewhere in the continuum from SWIG through XS and on to Platypus there are also the Inline modules these days. They allow one to put inline sections of other languages into Perl code the way many language tools used to allow one to inline assembly into C or Pascal code.
There are some of these modules for other languages than those listed here, a lot of them as high level as Perl (including Raku and even another Perl system for some reason).
https://metacpan.org/dist/Inline-C/view/lib/Inline/C.pod
https://metacpan.org/dist/Inline-ASM/view/ASM.pod
https://metacpan.org/dist/Inline-CPP/view/lib/Inline/CPP.pod
https://metacpan.org/dist/Inline-CPR/view/CPR.pod
https://metacpan.org/pod/Inline::Lua
https://metacpan.org/dist/Inline-Java/view/lib/Inline/Java.p...
https://metacpan.org/pod/Inline::Guile
https://metacpan.org/dist/Inline-SLang/view/SLang.pod
There are even tools to convert from Inline to XS for C and C++.
https://metacpan.org/dist/InlineX-CPP2XS/view/CPP2XS-Cookboo...
https://metacpan.org/pod/InlineX::XS
True. For whatever reason, these never displaced XS. For wrapping C libraries in particular, it's not clear to me how much Inline::C helps with this. You're still stuck using a lot of Perl C API calls, AFAICT, which I think is the biggest challenge of using XS (I still have nightmares from trying to figure out where and when to add `sv2mortal` in my XS code).
I haven’t done nearly as much of this as you.
One or two calls into a library with a simple C interface isn’t that bad with Inline. You just use Inline to handle the Perl to C to Perl part, and actually do the interfacing in the inline C. It’s a lot more mess if you’re doing complex things and bringing complex data structures back to Perl, or having Perl make a lot of intermediate decisions and doing a lot of round trips. So if you use Perl to get the data ready to pass in, pass it in, do all the work in C that you need the library for, then pass the results back to Perl once it’s not terrible.
I’ve tried not to get into XS, so I couldn’t really compare.
Using Inline::C with your own C code in places where Perl is too much overhead is certainly easier than wrapping a complex existing library with a lot of interactions across the boundary.
FFI::Platypus or something like it really is the way of the future though for existing C calling convention libraries in other languages.
Perl 5.
Perl 4 was a great upgrade to bash as a scripting language. Perl 5 added a bunch of complexity to remake Perl into a programming language. It failed.
Perl 4 was a great scripting language whereas Perl 5 was a terrible programing language. Perl 5 lost to the better (dynamic) programming languages and bash reclaimed the scripting title as Perl 4 was dead.
I haven't written perl in a long time but I cannot put a finger on why I stopped using it.
It used to be my goto language for quick and dirty scripts that needed somewhat non-trivial text processing.
Anyway, this made me think of the 2008 Damian Connway Perlcon keynote:
If you've never seen it it's worth a watch: https://www.youtube.com/watch?v=HzTjPx4NIiMI think it is due to the fact that Perl has some confusing bits like those variable prefixes ($@%), the lack of function arguments (I know that this has changed recently), not really great error handling, etc and so people started using languages which seemed easier to use like Python.
The variable prefixes are just the tip of the iceberg. The real problem with those prefixes is that they, themselves, are context-dependent on attributes associated with the underlying data type at run time. So you can find yourself in a situation where the behavior of the syntax differs in ways that are difficult to control for during development.
Strongly agree. A language which has something like “wantarray” as a first-class feature is semantically…unique, at best, probably more like “flawed by design”. All the oddness with typing and sigls descends from that.
Same for autovivification. Insane feature. Useful for some problems but causes many more.
Which is a shame, because perl5 semantics had some nice features too! But there’s only so much you can do with a structure whose foundation is so wacky.
I remember trying to use the new "reference" feature (when it was new), with "blessing" and so on and so forth, to try to create real data structures, and finding in some way or another that it was just not regular. I can't recall the details, but something along the lines of a feeling that the syntax worked differently for, say, the top level of a tree (or first index of a multidimensional array, etc.) vs the rest of the structure.
Yep, there're all sorts of things like this in Perl. Its semantics has always been confusing to me.
Yep. Perl the first language I ever used to professionally do something approximating "real programming" (as opposed to one-off scripting). And then I learned Python and never touched Perl again ... at least at the time, to my very inexperienced self, it felt like an improvement on every single axis.
In retrospect, probably 90% of my enthusiasm for python over perl was just "if you use python, you never have to think about variable sigils ever again." That and `string.split()`.
> the lack of function arguments (I know that this has changed recently)
Real arguments were added as of perl 5.20, which was in 2014.
Yes, that's almost as old as some currently-hyped programming languages. But it's quite new compared to the natural behaviour of some developers (a fact that I used to find surprising and now just find disappointing).
Comparably: today, in the Python world, people are praising tools like uv because now they "don't have to understand virtual environments". And continuously since the introduction of PEP 668 three years ago, people have been grumbling about the expectation to leave "externally managed environments" alone. But uv still uses virtual environments; and `venv` has been in the standard library since 2012, and the third-party `virtualenv` that it's based on has been available since 2007.
That's "recently", relative to Perl's heyday.
I learned and used Perl professionally from around 2005-2015 and experienced first-hand the ossification, fear of change, and lack of innovation in Perl 5 development. It seems all the talent and effort started being wasted on making Perl 6 the bestest, most elegant, most useful programming language in the world. Just seeing the neglect of Perl 5 kept me from ever considering Perl 6 and motivated me to move to other languages.
I started learn Perl 5 right before 6 was announced. When I saw what was happening with Perl 6, I decided just to stick with sh, awk and friends.
IIRC, The Perl 6 development thing went on for a very long time and got nothing but bad press. That took the wind out of my sails.
My experience of working with Perl as a primary language from late 90s to today: Perl was dead long before Perl 6/Raku was a real thing. By the time that happened it had already lost massive ground to PHP, Python, Java, etc.
PHP had replaced CGI as the easiest way to get code on a webserver, Python and Java were easier to read and understand, easier to structure large systems with, and generally easier to use. Ruby came along and MVC frameworks became the thing for complex web platforms.
Meanwhile Perl was sorta keeping up, the "Modern Perl" movement helped dispel myths about "write only" code, things like Moose, DBIC, Catalyst, Mojolicious, etc meant you could write pretty modern stuff with it. But the community was smaller, fractured by Perl 6 and dominated by some ahem divisive characters which made it intimidating for newcomers, and it just slowly died from there.
By the time Stack Overflow came along it was easy to see that other languages had vibrant communities surrounding them and for me it never really recovered.
I have great love for Perl, but I'm not super eager to go back to using it.
I used it in probably one of the more cursed contexts I've ever heard of. Understand[0] is a static analyzer for many languages, and one of its killer features is that it is programmable with a Perl API. I used this feature at a defense consulting job to help target audits of huge, multi-million LOC codebases.
Perl's expressivity was very useful here. I cut my teeth on functional programming concepts to write some very nice traversals. The runtime environment of the host program was a nightmare to deal with though.
[0]: https://scitools.com/
I learned Perl back in the day. It was fun and powerful.
But I think the package management and culture killed it for me. People took pride is writing obnoxiously messy code. Package dependency hell. Gung ho borderline toxic RTFM culture.
Personally, back when Perl 6 was harmless vaporware, I never found a place for Perl 5.
For moderately advanced text processing with regular expressions, supposedly its strong point, it was far less elegant and concise than AWK at the low end and far less readable and less batteries-included than Python for more complex tasks involving some integration.
For dynamic web pages, another of the main uses of Perl, PHP was purposefully designed and (while not really good) practical and user-friendly, with plenty of other obviously more robust and serious options (Ruby, Java, later Python, etc.) for more enterprise projects.
It sounds like Perl just wasn't your style and that's okay.
But, Perl was immensely popular, particularly in the 1990s in its 4.x/5.x days. We used it because it was precisely more elegant, ergonomic and performant than awk :-)
Later on, Python gained more traction because it was more batteries-included, and PHP evolved from being a toy named "Personal Home Page".
Perl was immensely popular, but it isn't necessarily enough to qualify for the personal "bubble" of languages one learns. It was a good choice of proven, general purpose interpreted scripting language for you in a time when Perl competed with AWK and shell scripts, but in the 1990s I used mainly C and C++ before adopting Java quite early and almost exclusively; when I later decided to learn some proven, general purpose interpreted scripting language Python was my obvious choice: more advanced than Perl 5 and more popular than Ruby.
Back in the day it was Perl or PHP on the web
I was a Perl programmer, and I looked down my nose at PHP. Silly me, then and now
Why did PHP, an objectively a worse language, win?
Rasmus Lerdorf said in a quote I can no longer find, it was modperl vs. modphp for Apache.
Modperl was, typically for Perl, very comprehensive and allowed access to all the Apache processing hooks
Modphp was, typically for PHP, just enough to speed up rendering so only allowed access to the barest minimal set of hooks
Modperl, so much better (I can hear myself say 30 years ago)
But at the time most websites, by count not by traffic, ran on shared hosts where the system administrator gave you access to software. If they installed mosdperl you would be able to intercept, read, and change traffic for all websites hosted on that machine
Modphp, not so.
So PHP was widely available to the pioneers in the day, people scratching together a little web hosting business and growing . Perl was not
Not enough on its own to kill Perl, but an important nail in its coffin
From a recruiter’s perspective, I remember recruiting full stack Perl people for a San Jose based tech company in 2010. I was able to secure one really good Perl guy who had just been laid off from Yahoo, but there just wasn’t anyone else who was relatively easy to find with the experience this company wanted. I was charging by the hour, and I distinctly remember suggesting that the company consider hiring non-Perl people and letting them learn on the job as I wasn’t going to be able to find what they wanted. They kept looking for Perl people and I kept charging them. I wasn’t shocked when an executive at the company eventually asked why the recruiting bill was so high given the lack of results.
I use shell, vim, sed all the time (awk less but i have used it). I've never used perl. I don't even know if i've ever even encountered a perl program that i wanted to look inside.
I think its just one of those things, they lost mindshare and people stopped making stuff in perl. Network effects made it snowball from there. How often do you see code examples written in perl? Almost never. I see people write blogs with code snippets in python, c, rust or even shell all the time. Never perl.
Momentum matters and perl lost it. I think of perl the same way i think of cobol or fortran.
You really think that Perl has billions of lines in active use in critical applications and libraries?
Back in 1994, Perl was an amazing thing to me (as someone who was accustomed to mainframe scripting languages up to that point), and it helped make me very productive. But it sometimes would seem like the epitome of "Write once, read never". Tim Bray even remarked on its abstruseness back in 2003:
https://www.tbray.org/ongoing/When/200x/2003/07/31/PerlAngst
I still use perl. It's my go to for string parsing (think pipe log file, do something with it and send it to stdout). It's also my go to for anything that I still want to work in 10 years.
Perl is powerful, expressive, and cryptic. Its popularity faded during a time when the popular trend of programming languages was towards simplicity and legibility. C++ gave way to Java and C#.
Also, Perl's strength was text processing in a world where data was moving out of simple columnar text formats and into databases, xml, json, and other formats better represented by object models than lines of text.
Even before the Perl 6 insanity dropped, there was a serious underlying problem in the Perl ecosystem: CPAN. There was this module (I don't remember its name, or author) that was pretty important: you'd end up using it if you were serious about Perl.
One day, around 2000 or so, the author/maintainer, a well-known guy in the Perl community, updated the package with an incompatible API. If you used that package, you had to update your code. There was no backward compatibility, nothing. To make things worse, the README stated that it would AGAIN change API in the future, but he didn't know yet what the change would be.
I considered this disastrous maintainer behavior, as I'm sure anyone reasonable would. It was clear I had to stop using this package, and anything else this guy could get his claws on. But there really wasn't a massive outcry that I could see, nobody calling him out for this crap.
That's when I knew I had to stop writing code in Perl. I tried Ruby but found it unstable at that time. Next project I used Python, and never looked back.
Simply python being pushed / sponsored by google? Was python all that popular before that? It had fans, of course - but was it an automatic go-to?
Python claimed to be simple - which fit well with the "line noise", erm... propaganda.
I sometimes wonder how different things might have been if Perl had been the dominant scripting language at the time that ChatGPT, Codex, Claude Code and other tools like that became available.
Would Python have been able to compete, in a world where Perl could be readily comprehended by LLMs?
So, maybe what killed Perl was lack of VS Code forks and lack of being agentic.
Perl is what killed Perl. I have never had as many "tear my hair out at 4AM" debugging sessions as I have had with Perl, because I missed some weird character somewhere.
I love Perl. I think, though, that the crazy mix of sigils and braces/brackets to work with complex data structures was one of the main reasons.
Especially for the type of users were Perl had gained some ground in the past...data science, DNA related stuff, etc. Non programmers.
If you look at just about any other language and how you would pull data in and out of json yaml, manipulate individual elements, etc... the Perl is just hard to decipher if you don't have immediate recall of all the crazy syntax for dereferencing things.
It killed itself. I always remember the joke about any random sequence of characters and numbers being a valid Perl program.
More importantly, there's hardly a problem that can't be solved in a much better way through other means.
I still use Perl everyday. I know it isn't as popular as when I learned it in the 1990's but I process so many text logs that I find it very useful.
I use Raku on a regular basis. I think it is the best language to write DevOps (for lack of a better term) scripts.
Perfect for people who find Bash too sharp and fragile and Python too tedious.
What put perl out to pasture for me was lack of static types, nor any capability of adopting them. We were told to wait for Perl 6 for that, and well, we saw how that went. I'm told that disabling indirect object syntax gives Perl a fighting chance at static analysis, but that in the end it's still the case that only Perl can parse Perl.
It was never about Perl, it was the plethora of alternatives.
Python evolved, PHP had 1000 times more "how to get started" articles, Node happened. And LAMP became the default for noobs.
As someone that was already working during the dotcom wave, Perl is a tool I would still reach for, given the problem I might trying to sort out, if on an UNIX like platform.
> Binary package managers that chase down dependencies on their own weren’t a thing until the early 2000s, I think?
UNIX package managers started to be made available during the 1990's.
Yes, but they were either source package managers or they didn't resolve dependencies transitively, only complained about missing direct dependencies.
I might be using strange versions of Red-Hat, Mandrake, SuSE, Aix and Solaris, then.
I definitely had Debian installs pulling binary package dependencies automagically via apt-get in 1999, and I think similar with RedHat a year or so before that.
Though that doesn't cover much of the 90s.
About a dozen years ago, I noticed that the young all seemed to know Python, and did not seem to know Perl. Given that they would be maintaining such code as I wrote and was worth keeping around, I moved to writing in Python. Now when I write Perl, I do silly things like forget semicolons.
Perl can be very well written. I deeply regret not encountering Perl Best Practices when it came out.
Expecting the Perl community, with it's TMTOWTDI (There's More than One Way to Do It) ethos, to come together and be the drivers of the next version.
My personal reason was observing the huge amount of investments into Javascript and its infrastructure (by Google and others). After Node.js was released it was a rational bet to make that Javascript would dominate, both server and client side. As someone who often does both front end and back end, it felt good to move to Javascript. It's got to be said that keeping a "common" directory around with shared code for both front- and backend is still a PITA, but still better than most other alternatives.
I have two programming language tattoos: A Perl camel, and a Ruby ruby.
For me, that's the answer to this question: Ruby had all the stuff I liked from Perl, and didn't have the stuff I didn't like. It's just that simple.
One thing I miss to this day is how ergonomic regular expressions are in Perl 5.
Dude, a lot of the string handling stuff in Perl was great!
Around 2010 I ditched Perl for PHP because I had been using PHP for web and could write the same systems scripts in PHP as I used to write in Perl. Sticking with one go-to language is easier on the brain.
It would literally just be Python (and probably some php and maybe even ruby) plus "Bash is good enough and more ubiquitous for the things you don't need all of Python for," no?
Nobody we've hired in the last 10 years wants to touch anything Perl.
That said, we re-wrote all of our monitoring scripts in....Bash.
Ugh.
Perl died because more shared web hosting installs supported PHP than Perl.
This reminds me of the april fools email from Richard Stallman to rewrite Emacs with Perl https://www.gnu.org/fun/jokes/gnuemacs.en.html
Is it worth learning Perl 5 these days? Maybe to use as a better Bash?
It's definitely more powerful and has less foot guns than bash, the problem is the stigma is worse than bash. You will face more scrutiny and possible derision from your colleagues for using Perl than bash. It's not just questioning your taste or style either, it's because of the fear they might have to one day maintain or try to understand your Perl.
I speak from some experience. Because I'm a 90s UNIX nerd, I quickly hacked up a a bunch of stuff in Perl maybe 6 years ago to solve some text processing tasks for a compliance audit. It worked well and got the job done within the time constraints. I actually got some kudos for getting our team out of a jam and doing grungy work people weren't keen to do. My teammates though, they lost no opportunity to dunk on the fact that it was done in Perl, and questioned my decision at every opportunity. I ended up rewriting the whole thing in Python for our next audit.
The opinion of coworkers is not a factor - but I have a friend who says that he has to relearn Perl every time he needs to use it. Do you have to use it every day to maintain fluency?
It doesn't take too long to get back into the swing of things. After a while, if you learn enough programming languages, they all tend to meld together in your brain, and the cost of switching isn't too disruptive. You know what you want to do, it's just the details that temporarily get in your way.
> Maybe to use as a better Bash?
If you know Python, just switch to xonsh (https://xon.sh/). I've been using it as my primary shell since 2018.
It’s strong as a better shell. Perl is even getting an increasingly good and complete default object model in the core language. One of the big complaints was always that the TIMTOWTDI included object libraries, of which there are many. Most of the popular ones are working on becoming wrappers around the new core one, and you can write new code directly with what’s in core.
I may blog about this next year, again[^1], as I'm working on a project that sort of covers it - not in a way that will answer the question but more observational.
Anyway, I feel Perl's popularity was hugely exaggerated in the mid to late 90s and early 00s. The alternatives were either not there in terms of language and toolchain features, ease of use, "whipuptitude" or whatever, or library support (CPAN was a killer app), or they were too old school or enterprisey. Sysadmins were using it everywhere so it got into all sorts of systems that other languages couldn't without much more faff.
Its back compatibility meant it stayed in those places for a long time. It's still in a lot of those places.
The fall in popularity the last decade or two was more of a regression to the mean, or perhaps below the mean. Many other languages have come along, which have contributed even more to the fall in share.
Yes, yes, Raku (né Perl 6) but I'd argue that also contributed to a lot of really good stuff on CPAN. The Perl 5 core did get neglected for a number of years, as @autarch says, which may have been a factor.
[^1] previously: https://leejo.github.io/2017/12/17/tpc_and_the_end_of_langua...
I heard a fascinating theory a few years ago on the decline of Perl:
In the early aughts, Google SRE recruiting had such a strong, selective focus on A-player sysadmins with Perl expertise that it drained the market of top talent. Within google these people began to adopt, and eventually create and evangelize newer, Googlier programming languages.
In other words, Perl expertise was the skills filter, and Perl itself a technological ancestor of certain modern languages like Go.
I don’t think Google was ever a Perl shop. eBay and Amazon were, apparently. Netscape wrote Bugzilla in Perl. I’m sure there were others.
I worked at Booking.com for a year or so around 10 years or so, and most of their stack was in Perl. Folks there had mixed feelings about it, I'm not sure what things are like now, but I assume they're working to replace it.
Yahoo! had a shitload of Perl.
IMDB is the one I always think of.
chunks of Amazon were still in Perl while we were building out IMDb.
Nonsense. Google only ever hired one perl5 committer, who never actually committed anything.
Been using Perl since the beginning… essentially every time I needed to write a shell script more than 10 lines long I used Perl … eventually was also using it for web back end stuff too … kind of like duct tape. I still use it today if I need to write more than 10 lines of a bash script.
Same here. I use Raku instead.
Easier to learn languages came along.
Perl stems from a time where COBOL, FORTRAN, and SQL made sense and it was already mind bending for those accustomed to those old languages.
Modern minds can't comprehend Perl.
I was a happy perl user for a long time, probably until sometime in the early 2010s. I am a sysadmin and perl was a great tool for what I needed to do.
Jim Weirich was a heavy perl user for a long time, and we were both involved in the Cincinnati perl mongers group. He found ruby and fell in love. He thought Ruby would be a good fit for me and we had a long conversation about why he preferred it to perl. It took me a few years, but I eventually took his advice. As usual, Jim was right, and I haven't written any perl since then.
tl;dr: for me, ruby killed perl.
After twenty years of Perl, I switched to Python because I was encountering too many useful frameworks and systems that had no corresponding Perl packages. The last straw was when I wanted to use Mongo and found that the Perl package was unsupported.
Python.
And PHP.
I spent 10 years in perl and created a lot in it - it taught me a lot about code as a culture,importance of tests, TIMTOWTDI, etc. I think I owe a lot to it.
I found myself defending it more and more online against the folks who were nay sayers - those who complained about its syntax and it's quirks - but that wasn't a problem for unixers who used sed/awk/vim and all the other arcane tools. Perl wawa means to and end and it was the best tool to reach for (the glorious Swiss army knife).
I guess there was an infection period - the brain drain to python and Ruby meant it was harder to find decent quality libs on CPAN anymore as folks would only do things in python. And Yea, while CPAN is still rich, it's not the first hit on Google anymore.
Today, the map-sort-map Schwarzian transform is still the easiest to do in perl than any other language and it helps me whip up the throwaway scripts quick. Wouldn't change the language - I really love it!
Instead of a Swiss army knife, I always heard it referred to as a "swiss army chainsaw" lol.
In all seriousness mod_php killed Perl, or at least struck the fatal blow. In the late 90s I wanted to make dynamic web content, just simple CRUD stuff. The most reliable way to do this was Perl. As long as your hash bang and permissions were correct you could drop a script in a cgi-bin directory and it would work. It didn't matter if the server was Solaris, Linux, or some other Unix. Most hosts that supported Perl also at least had the CGI module installed as well.
It was worth fighting with Perl's syntax because it was the best option for web programming (for random amateurs like myself). Web hosts often didn't have C compilers available so C wasn't an option. TCL was workable but not as prevalent as Perl on web hosts. Same with PHP3. Keep in mind this was an era where you were deploying on machines you didn't on which you didn't have admin access. Most of the time you didn't have shell access on machines you'd deploy on.
As Linux adoption on servers exploded so did the deployment of PHP. It was easy to deploy PHP web apps since they could be readily dropped in your htdocs or public_html directory and be handled by the server. Enabling other CGI outside cgi-bin directories was uncommon.
So by 2000 or so there was no reason to learn Perl to do web stuff easily. You could do it in PHP which was already a templating language. The younger version of me that wanted to do web CRUD stuff bought a PHP book instead of a Perl book. With Python 2's release at that same time if you wanted to do portable non-web stuff you had a much nicer language than Perl available as well.
It was too simple.
(map { $~ =~ s/.*/$&/r } split /\s/, $^W x $/ ) ~~ tr/a-z/x/r x $!
Raku
Perl was the internet in 1990s. People (me) who were doing unix systems work (C, shell, Perl and some DBs and FTPs) could now quickly throw a CGI script behind an Apache HTTP server, which tended to be up and running in many unixes :80 port back then (Digi, HP, Sun, etc). Suddenly I had a working app that would generate reports directly to people's browsers or full-blown apps on the internet! But Perl CGI did not scale at all (spawn 1 short-lived process per request will choke a unix fast), and even after mod_perl [1], that got quickly superseded by PHP, which was really built for the web (of the 1990s). Web frameworks and fastcgi arrived too late to Perl, so internet Perl was practically dead at the turn of the century.
The enterprise, who either did not have any webapps or had tried Perl CGI first and suffered it dearly, got pinged by their sales reps that Java and .NET (depending if you were a IBM, Sun or MS shop) were the way to go, and there they went with their patterns and anti-patterns for "scalable" million-dollar web stacks. That kicked-off the age of the famed application servers that resist up until today (Websphere, Weblogic, etc).
So Perl went back to being a glue language for stitching up data, C/C++ and shell, and that's how the 2000s went by. But by then, Ruby and Python had more sane communities and Ruby was exciting and Python was simpler - Perl folks were just too peculiar, funny and nerdy to be taken seriously by a slick new generation that coded fast and had startup aspirations of the "only $1B is cool" types. Also the Perl6 delusion was too distracting to make anyone event care about giving Perl5 some good love (the real perl keeping servers running worldwide), so by the 2010s Perl was shooting down to collective ostracism, even though it still runs extremely well, fast and reliably in production. By the 2020s the release cycles were improved after Perl6 became a truly separate project (Raku, renamed in 2019), the core has gone through a relative cleanup and finally got a few popular features in demand [3]. The stack and ecosystem is holding up fine, although CPAN probably needs some good tidying up.
The main issue with Perl at this point is that it has not been a target for any new stuff that comes out: any cool module, library, database, etc that is launched does not put out a Perl api or a simple example of any kind, so it's up to the Perl community to release and maintain apis and integrations to the popular stacks on its own, which is a losing game and ends up being the nail-in-the-coffin. By the way, nothing (OSS) that comes out today is even written in Perl. That reduces even further the appeal of learning Perl.
Strangely enough, lately Perl has seen a sudden rise in the TIOBE index [4] back into a quite respectable 9th position. TIOBE ranks search queries for X language and is not much of a indicator, being quite noisy and unreliable. My guess is that those queries are issued by AI agents/chats desperately scraping information so that it can answer questions and help humans code in a language that is not well-represented in the training datasets.
[1] mod_perl was released in 1996, and became popular around 1999: https://perl.apache.org/about/history.html
[2] PHP was released 1994, took off ~1998 with PHP3: https://www.php.net/manual/en/history.php.php
[3] Perl's version changes simplified: https://en.wikipedia.org/wiki/Perl_5_version_history
[4] https://www.tiobe.com/tiobe-index/
I know, but I won't tell you