Python says you know nothing, but want to automate a small task. The community will help you. More so than any other language.
Then again, Python 2 and Python 3 are two different languages.
Very few projects are willing to have such a massive migration.
Any one ( and I'm sure a few have tried) can fork 2.x and keep using it.
3.x is remarkably easy , you can probably onboard a non programer to Python in a month.
It was Django and the people involved with it.
Culture?
But, shell scripting has already become somewhat of an arcane skill. I think the article nailed that Perl was just too hard to learn for the value it provided to survive. Python is not nearly as, erm, expressive as perl for working in that space, but it is much easier to learn, both in terms of reading and writing. In other words, it encourages broadly maintainable code. Ruby is quite similar (although I think people massively overstate how much the language itself generally encourages understandable semantics)
Python is a crappy shell scripting language because the syntax around pipe and subprocess is really clunky.
Perl managed to have decent data structures and also have decent syntax around subprocess calls.
But I feel like the Python invoke module gives me everything I need wrt subprocess calls. I basically write any nontrivial "shell script" these days as a Python invoke command.
GvR explicitly describes the motivation behind Python in similar terms (I can probably find a timestamp in that recent documentary for this). But the goal there was to be fully "general purpose" (and readable and pragmatic, more than artistic) while trying to capture what he saw as the good things about shell languages.
And it's changed quite a bit since then, and there are many things I would say with the benefit of hindsight were clear missteps.
We all joke about the hard problems of computer science, but it seems to me that the hard problems of programming language design, specifically (and perhaps software engineering more generally?) include having good taste and figuring out what to do about reverse compatibility.
> I think the article nailed that Perl was just too hard to learn for the value it provided to survive. Python is not nearly as, erm, expressive as perl for working in that space, but it is much easier to learn
The use cases have also changed over time. Quite a lot of developers ended up on Windows (although that pendulum is perhaps shifting again) where the rules and expectations of "shell" are very different. To say nothing of e.g. web development; long gone are the days of "cgi-bin" everywhere.
And that could be one of major reasons why it lost in popularity. It was and still is easy to write but hard to read.
my @var = @array # copy the array
my $var = @array # return the count of elements in array my($f) = `fortune`; # assigns first line of output to $f.
my $f = `fortune`; # assign all output to $f.
[^1]: "It's all about context" (2001): https://archive.ph/IB2kR (http://www.stonehenge.com/merlyn/UnixReview/col38.html)
His point about references is no small thing. Other dynamic languages don’t make users think much about the distinction between references and values at the syntax level. With Perl you needed to use “->” arrow operator frequently if and only if you were using references. So getting at a map inside an array or vice versa had its own syntax vs reading a string in a map or array.
Also it had bolted on, awkward OO on top of the bolted on, awkward params passing. You literally had to shift “self” (or “this”) off a magical array variable (@_).
By default it wouldn’t warn if you tried to read from an undeclared variable or tried to use one in a conditional or assign from one. You had to declare “use strict;” for that. Which wasn’t hard! But these awkward things piled up, a bunch of small cuts. Don’t forget “use warnings;” also, another thing to put at the top of every Perl file.
To the extent its awkward syntax came out of aping of shell and common Unix cli tools, you could maybe see it as cultural issue if you squint.
But any language in the mid 90s was infected with the “rtfm” priesthood vibe the author writes about, because the internet then was disproportionately populated by those sysop types, especially the part that can answer programming language questions on usenet, which is basically where you had to ask back then.
So for example Rails won for technical reasons, it is much more concise with fewer footguns than its Perl equivalents. I was actively coding web stuff in Perl when it came along and early switched. It wasn’t a cultural thing, having choice in Perl was fine (and ruby has sadly never grown much culture outside Rails - it could really use some). It probably did help that it came along in the mid aughts by which time you could ask questions on the web instead of Usenet. And it used YouTube for that first rails demo. So ruby did end up with a less sysopy culture but that had more to do with the timing of its success than the success itself.
Perl is not that good a language though for practical purposes. The same way, a breadboard contraption is not what you want to ship as your hardware product, but without it, and the mistakes made and addressed while tinkering with it, the sleek consumer-grade PCB won't be possible to design.
Perl lets every developer write Perl in their own idiosyncratic way.
And every developer does.
It makes for very un-fun times when I'm having to read a file that's been authored by ten developers over ten years, each of whom with varying opinions and skill levels.
I guess in 2026, it'll be 11 developers writing it over 11 years. My sincere apologies to those who come after me, and my sincere fuck-you to those who came before me. :)
And that was, paraphrased: make the way you want something to be used be the most concise way to use it and make the more obscure features be wordy.
This could have been the backbone of an entire community but they diminished it to code golf.
Unfortunately, as a former Perl dev, it makes a lot of other environments feel bland. Often more productive yes, but bland nonetheless. Of the newer languages, Nim does have that non-bland feel. Whether it ends up with significant adoption when Rust and Golang are well established is a different story.
Python 3 almost killed Python.
It's normal. Once a community loses faith, it's hard to stop them from leaving.
People were being crybabies; the critics were extremely vocal and few. Python 3 improved the language in every way and the tooling to upgrade remains unmatched.
Organizations struggled with it but they struggle with basically every breaking change. I was on the tooling team that helped an organization handle the transition of about 5 million lines of data science code from python 2.7 to 3.2. We also had to handle other breaking changes like airflow upgrades, spark 2->3, intel->amd->graviton.
At that scale all those changes are a big deal. Heck even the pickle protocol change in Python 3.8 was a big deal for us. I wouldn't characterize the python 2->3 transition as a significantly bigger deal than some of the others. In many ways it was easier because so much hay was made about it there was a lot of knowledge and tooling.
They should've just used Python 2's strings as UTF-8. No need to break every existing program, just deprecate and discourage the old Python Unicode type. The new Unicode type (Python 3's string) is a complicated mess, and anyone who thinks it is simple and clean isn't aware of what's going on under the hood.
Having your strings be a simple array of bytes, which might be UTF-8 or WTF-8, seems to be working out pretty well for Go.
I do imagine a saner migration could've been done - for example, declaring that regexes must not start with a non-escaped space and division must be surrounded by space, to fix one of the parsing problems - with the usual `use` incremental migration.
In my mind (developer back then) I'd amateur-psychoanalyze all of that nonsense as some kind of inferiority complex meant to preserve the self image. Needless complexity can be a feature!
And now we are all developers!
Edit: But I see your point, Google SRE’s around the late 2000’s reached for Python more than Perl.
Some of it I recognize as being an artefact of the time, when conciseness really mattered. But it's still obnoxious in 2025.
The whole thing reminds me of D&D, which is full of classes & spells that only exist in modern D&D because of One Guy who happened to be at the table with Gygax, who really wanted to be a wuxia guy he saw in a movie, or because he really wanted a spell to be applicable for that one night at the table, and now it's hard-coded into the game.
Because of this, in practice, the amount of system administration mantainence and care needed for perl programs is far, far less than other languages like python where you actually do have to go in and re-write it all the time due to dep hell and rapid changes/improvements to the language. For corporate application use cases these re-writes are happening anyway all the time so it doesn't matter. But for system administration it's a significant difference.
I still remember spending time with my coworkers on bench outside of building trying to figure out #@$%$^&$%@something = []sd[dsd]@$#!&lala lines written by previous developers
I was aware of ActivePerl and quite liked Komodo. Thankfully I could keep myself from doing things on Windows/IIS apart from a brief stint writing a single file CMS in ASP.
as backend we had oracle. at first we tried oracle/linux (just released). but we never managed make it work (oracle engineers that came to us failed as well). So we got dedicated sun server for it.
One day I was bored, installed mysql on my workstation, made a changes in couple of queries and all of sudden i got x20 performance of sun box with oracle. Lead developer said that it's bad solution as mysql doesn't properly supports referential integrity (we didn't actually used it in oracle iirc)
The original intent was you could see var types with them - $scalar, @array, %hash.
They immediately broke this by deciding the sigil would apply to the value /extracted/ from the data structure. So you declared array @foo but accessed an element as $foo[1]. What? There’s a logic there but already you’re violating many people’s expectations so why even have them. The sigils are now confusing many people instead of clarifying anything.
The sigil idea then /completely/ failed when they introduced references and “complex data structures” (nesting arrays within arrays like every other language - in Perl this was a special thing because they had been flattening lists by default so no way to put one inside another).
So now to get at a hash in a hash you used not % but $ since a reference is a scalar. $hash1->$hash2->{“key”}. Versus $hash3{“key”} for a simple hash. Just awful noisy syntax. Due to poor language design up front.
maybe its painful for guys to admit that languages could be a lot better designed, and when such langauges appeared, everyone flocked to them.
Perl was my first language because I wanted to make interactive websites and that was the most common way to do it in the late 90s. Shortly after, everyone switched to PHP because mod_php was much faster than Perl CGI scripts.
And serving it tends to be "copy the files to your web server's public dir".
If Perl had had a good culture, then conserving it would have been good!
A shift to Python or Ruby is fundamentally a shift to a different set of core cognitive patterns. This influences how problems are solved and how sense is made of the world, with the programming languages being tools to facilitate and, more often than not, shepherd thought processes.
The culture shift we have seen with corporations and socialized practices for collaboration, coding conventions, and more coincides with the decline of a language that does in fact have a culture that demands you RTFM. Now, the dominant culture in tech is one that either centralizes solutions to extract and rent seek or that pretends that complexity and nuance does not exist so as to move as quickly as possible, externalizing the consequences until later.
If you've been on this forum for a while, what I am saying should seem familiar, because the foundations have already been laid out in "The Pervert's Guide to Computer Programming", which applies Lacanian psychoanalysis to cognitive patterns present in various languages[1][2]. This explains the so-called decline of Perl—many people still quietly use it in the background. It also explains the conflict between Rust and C culture.
As an aside, I created a tool that can use this analysis to help companies hire devs even if they use unorthodox languages like Zig or Nim. I also briefly explored exposing it as a SaaS to help HR make sense of this (since most HR generalists don't code and so have to go with their gut on interviews, which requires them to repeat what they have already seen). With that stated, I don't believe there is a large enough market for such a tool in this hiring economy. I could be wrong.
[1] [PDF] -- "The Pervert's Guide to Computer Programming" https://s3-us-west-2.amazonaws.com/vulk-blog/ThePervertsGuid...
[2] [YouTube Vulc Coop]-- https://www.youtube.com/watch?v=mZyvIHYn2zk
However, I used Perl and stopped using it without knowing anything about its internal politics or community. PHP, ASP, Java JSP and later Rails were much better than Perl for web development.
* I know that for some the mention of JSP will be rare, as it was ugly… However in the 2000s it was the state of the art
The mentality described here has always galled me. Half the reason I’m willing to scramble up these hills is to gain the perspective to look for an easier way up the next time. It’s my reward for slogging through, not for the gathering of sycophants.
I’m not sure you’ve mastered a thing until you’ve changed the recipe to make it a little bit better anyway. My favorite pumpkin pie recipe, isn’t. As written the order of operation creates clumps, which can only be cured with an electric mixer. You shouldn’t need an electric mixer to mix pumpkin pie filling. If you mix all the dry ingredients first, you get no clumps. And it’s too soupy. Needs jumbo eggs, not large. So that is my favorite recipe.
But maybe this is why I end up writing so many tools and so much documentation, instead of hoarding.
Python is pretty good too for this and because modern computers are so fast it doesn't matter that it's much slower than perl, but if you're doing something like processing terabytes of files, it's probably worth your time to find or vibe code a one-liner in perl and torture it into working for your task.
superkuh•51m ago
This kind of ubiquitous availablility (from early popularity) combined with the huge drop-off in popularity due to raku/etc, lead to a unique and very valuable situation unmatched by any other comparable language. Perl just works everywhere. No containers, no dep hell, no specific versions of the language needed. Perl is Perl and it does what it always has reliably.
I love it. The decline was a savior.
keepamovin•44m ago
pomatic•15m ago
amiga386•35m ago
By comparison, Python can barely go one version without both introducing new things and removing old things from the language, so anything written in Python is only safe for a a fragile, narrow window of versions, and anything written for it needs to keep being updated just to stay where it is.
Python interpreter: if you can tell "print" is being used as a keyword rather than a function call, in order to scold the programmer for doing that, you can equally just perform the function call.
0xDEAFBEAD•18m ago
zahlman•12m ago
Overwhelmingly, what gets removed is from the standard library, and it's extremely old stuff. As recently as 3.11 you could use `distutils` (the predecessor to Setuptools). And in 3.12 you could still use `pipes` (a predecessor to `subprocess` that nobody ever talked about even when `subprocess` was new; `subprocess` was viewed as directly replacing DIY with `os.system` and the `os.exec` family). And `sunau`. And `telnetlib`.
Can you show me a real-world package that was held back because the code needed a feature or semantics
from the interpreter* of a 3.x Python version that was going EOL?> Python interpreter: if you can tell "print" is being used as a keyword rather than a function call, in order to scold the programmer for doing that, you can equally just perform the function call.
No, that doesn't work because the statement form has radically different semantics. You'd need to keep the entire grammar for it (and decide what to do if someone tries to embed a "print statement" in a larger expression). Plus the function calls can usually be parsed as the statement form with entirely permissible parentheses, so you have to decide whether a file that uses the statement should switch everything over to the legacy parsing. Plus the function call affords syntax that doesn't work with the original statement form, so you have to decide whether to accept those as well, or else how to report the error. Plus in 2.7, surrounding parentheses are not redundant, and change the meaning:
The incompatible bytes/string handling is also a fundamental shift. You would at least need a pragma.cedilla•30m ago
superkuh•28m ago