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.
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.
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 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.
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.
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.
"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.
TIMTOWTDI broke down with trying to do OOP in Perl. You could either bless a hash, or use a meta-object framework (moose?). You could end up with hierarchies of different types of objects with their own behavior.
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.
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.
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.
There are a few places where you might dig and find a perl script under the covers. Some that aren't replaceable with bash (and sed and awk).
I suspect that my "diff these two java deployments and create a file by file update script to run on the remote machine" in perl is still running for doing incremental deployments... and if someone uncovers it its still something reasonable to understand.
However, if I was tasked with that today... dunno. I'm not sure I'd reach for the same tools as I did then.
> In devops is turtle all way down but at bottom is perl script.
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.
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()`.
Perl originated from shell programming and inherited some of its patterns. If you ever looked at a bash script using arrays you will immediately recognize "@" to access the array as a whole and the switch to the "$" sigil to access a single element from that array. Perl was designed to make it easy for shell script writers to pick it up.
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.
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.
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 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.
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.
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.
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.
> 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.
> And Go came along and provided an aggressively mediocre but very usable
See, that's one of the things lots of people who enjoy Perl and/or Ruby in the comments around in this thread don't quite grasp: some languages require programmers possessing a somewhat special state of mind to read and write productively, and some languages allow pretty much every mediocre programmer to read and write, and still produce a manageable program.
The other thing is the information density. In my experience, most people after graduating high school have experience with reading mainstream fiction and school textbooks, and those things you can half-skim/half-read and still get out most of the meaning. Then those people hit the college-/university-level textbooks and screech and crash because those books, you have to read them sentence by sentence; not everyone can get get used to it (or even realize they have to do that in the first place). And similar observations hold for programming languages: Perl and APL are just way too dense compared to Go and Python; if you're used to reading code line-by-line (skimming over half of them), then it's really bloody annoying to switch to reading sigil-by-sigil (as for writing, well, we all know that typing speed was never really a bottleneck for programmers).
I wouldn't call making the right decision confused. It clarified and justified their desire not to use Perl. Only a confused CTO/VP Eng type would choose to use Perl in spite of all its entrenched disadvantages and much better more popular alternatives.
True. Adding to these. Perl6/Raku suffered from the second system effect. Described in the Mythical Man Month. Larry and company were over confident with their previous success.
I started programming in the late 90s using Perl as my first "real" language. When I first saw some Python code (2.3 if memory serves), I found it much easier to understand. Not necessarily easier to write, but diving into a Python codebase 6 months later was a lot easier than doing the same than with Perl. Purely subjective, but I was far from the only one, even if quite a few people at the time preferred Perl.
Later, when the Web really took off, running PHP 4 was much easier to get going than either Python or Perl, so a lot of us went with that.
And yeah afterwards JS with node.js in particular. The millions pumped into it by Google certainly helped.
There was also a time a bit later with Ruby getting really popular. Not just for new projects, I heard of some codebases migrating from Perl to Ruby, when the writing was on the wall for Perl 5.
Go, I think when it became popular not many people were still using Perl. Also not really something you would use to bang out a quick script with. Probably more of a competitor to Java.
As for me, back to Python as my bread and butter. Probably haven't touched Perl in 20 years at this point. Looks like gibberish to me now...
Perl was pretty much first in the wave of interpreted languages from the late 80ies and 90ies. It set the bar on what to expect from such ecosystems.
But being the first meant it got some oddities and the abstractions are not quite right imho.
A bit too Shell-esque, specially for arguments passing and the memory abstractions are a bit too leaky regarding memory management (reference management fills too C-esque for an interpreted language, and the whole $ % @ & dance is really confusing for an occasional and bad Perl dev like me). The "10 ways to do it" also hurts it. It lead to a lack of consistency & almost per developer coding coding styles. The meme was Perl is a "write only language".
But I would still be grateful of what it brought and how influential it was (I jock from time to time how Ruby is kind of the "true" Perl 6, it even has flip flops!).
In truth, these days, I feel the whole "interpreted languages" class is on the decline, at least on the server. There are a lot of really great native languages that have come up within the last few years, enabled in large part by LLVM. And this trend doesn't seem over yet.
Languages like Rust, Swift, Go, Zig or Odin are making the value proposition of interpreted languages (lower perf but faster iterations) less compelling by being convenient enough while retaining performance. In short, we can now "have the cake and eat it too".
But the millions of lines in production are also not going awywhere anytime soon. I bet even Perl will still be around somewhere (distro tooling, glue scripts, build infra, etc...) when I retire.
Anyway, thank you Perl, thank you Larry Wall, love your quotes.
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!
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.
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.
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.
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.
142 comments
[ 8.3 ms ] story [ 152 ms ] threadAs history has shown, this didn't work out well for anyone
Perl can be very well written. I deeply regret not encountering Perl Best Practices when it came out.
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.
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.
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.
> 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 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.
If you know Python, just switch to xonsh (https://xon.sh/). I've been using it as my primary shell since 2018.
There are a few places where you might dig and find a perl script under the covers. Some that aren't replaceable with bash (and sed and awk).
I suspect that my "diff these two java deployments and create a file by file update script to run on the remote machine" in perl is still running for doing incremental deployments... and if someone uncovers it its still something reasonable to understand.
However, if I was tasked with that today... dunno. I'm not sure I'd reach for the same tools as I did then.
> In devops is turtle all way down but at bottom is perl script.
https://x.com/DEVOPS_BORAT/status/248770195580125185 (2013)
> If you can not able use Perl for answer, you are ask wrong question.
https://x.com/DEVOPS_BORAT/status/280900066682757120 (2012)
... and while I can't find the original - this might be your answer.
> We have 3 strike rule for devops: 1 strike we are take away Perl. 2 strike we are take away bash. 3 strike we are give PowerShell.
https://gist.github.com/textarcana/676ef78b2912d42dbf355a2f7...
Real arguments were added as of perl 5.20, which was in 2014.
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()`.
Perl originated from shell programming and inherited some of its patterns. If you ever looked at a bash script using arrays you will immediately recognize "@" to access the array as a whole and the switch to the "$" sigil to access a single element from that array. Perl was designed to make it easy for shell script writers to pick it up.
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.
That said, we re-wrote all of our monitoring scripts in....Bash.
Ugh.
Python evolved, PHP had 1000 times more "how to get started" articles, Node happened. And LAMP became the default for noobs.
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.
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.
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.
Now, of course, that's a common and maybe even expected thing for a library to have: Python has Pypi, Javascript has NPM, etc.
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.
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.
As much as I liked Perl back in the day, it did sometimes earn its reputation as a write-only language!
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
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.
See, that's one of the things lots of people who enjoy Perl and/or Ruby in the comments around in this thread don't quite grasp: some languages require programmers possessing a somewhat special state of mind to read and write productively, and some languages allow pretty much every mediocre programmer to read and write, and still produce a manageable program.
The other thing is the information density. In my experience, most people after graduating high school have experience with reading mainstream fiction and school textbooks, and those things you can half-skim/half-read and still get out most of the meaning. Then those people hit the college-/university-level textbooks and screech and crash because those books, you have to read them sentence by sentence; not everyone can get get used to it (or even realize they have to do that in the first place). And similar observations hold for programming languages: Perl and APL are just way too dense compared to Go and Python; if you're used to reading code line-by-line (skimming over half of them), then it's really bloody annoying to switch to reading sigil-by-sigil (as for writing, well, we all know that typing speed was never really a bottleneck for programmers).
I wouldn't call making the right decision confused. It clarified and justified their desire not to use Perl. Only a confused CTO/VP Eng type would choose to use Perl in spite of all its entrenched disadvantages and much better more popular alternatives.
I started programming in the late 90s using Perl as my first "real" language. When I first saw some Python code (2.3 if memory serves), I found it much easier to understand. Not necessarily easier to write, but diving into a Python codebase 6 months later was a lot easier than doing the same than with Perl. Purely subjective, but I was far from the only one, even if quite a few people at the time preferred Perl.
Later, when the Web really took off, running PHP 4 was much easier to get going than either Python or Perl, so a lot of us went with that.
And yeah afterwards JS with node.js in particular. The millions pumped into it by Google certainly helped.
There was also a time a bit later with Ruby getting really popular. Not just for new projects, I heard of some codebases migrating from Perl to Ruby, when the writing was on the wall for Perl 5.
Go, I think when it became popular not many people were still using Perl. Also not really something you would use to bang out a quick script with. Probably more of a competitor to Java.
As for me, back to Python as my bread and butter. Probably haven't touched Perl in 20 years at this point. Looks like gibberish to me now...
But being the first meant it got some oddities and the abstractions are not quite right imho.
A bit too Shell-esque, specially for arguments passing and the memory abstractions are a bit too leaky regarding memory management (reference management fills too C-esque for an interpreted language, and the whole $ % @ & dance is really confusing for an occasional and bad Perl dev like me). The "10 ways to do it" also hurts it. It lead to a lack of consistency & almost per developer coding coding styles. The meme was Perl is a "write only language".
But I would still be grateful of what it brought and how influential it was (I jock from time to time how Ruby is kind of the "true" Perl 6, it even has flip flops!).
In truth, these days, I feel the whole "interpreted languages" class is on the decline, at least on the server. There are a lot of really great native languages that have come up within the last few years, enabled in large part by LLVM. And this trend doesn't seem over yet.
Languages like Rust, Swift, Go, Zig or Odin are making the value proposition of interpreted languages (lower perf but faster iterations) less compelling by being convenient enough while retaining performance. In short, we can now "have the cake and eat it too".
But the millions of lines in production are also not going awywhere anytime soon. I bet even Perl will still be around somewhere (distro tooling, glue scripts, build infra, etc...) when I retire.
Anyway, thank you Perl, thank you Larry Wall, love your quotes.
https://en.wikiquote.org/wiki/Larry_Wall
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!
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.
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.
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.