I always found the Perl "community" to be really off-putting with all the monk and wizard nonsense. Then there was the whole one-liner thing that was all about being clever and obscure. Everything about Python came off as being much more serious and normal for a young nerd who wasn't a theater kid.
I'm having to pick up some perl now, and while I don't interact with the community, it surely _feels_ like it was written by wizards, for wizards. Obscure, non-intuitive oneliners, syntax that feels like it was intentionally written to be complicated, and a few other things that feel impossible to understand without reading the docs. (Before everyone jumps on me - yes, as a developer, I should be able to read documentation. And I did. But until I did so, what the code was doing was completely opaque to me. That feels like bad language design.)
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.
Perl has always “flowed” for me and made mostly intuitive sense. Every other language I’ve had to hack on to get something done is a struggle for me to fit into some rigid-feeling mental box.
I understand I’m the weird one, but man I miss Perl being an acceptable language to pound out a quick program in between “bash script” and “real developer”.
Was Perl one of your first languages by any chance? I freely admit that I've only been poking at it for a few months; maybe by this time next year, I'll be boggled at the comment I left, like it was written by a different person.
> in between “bash script” and “real developer”.
One of my coworkers gave me some great perspective by saying, "at least it's not written in Bash!"
Yep, first language I learned. And since I was somewhat early to the Internet thing, I found IRC when I was about 14 years old and actually learned from a lot of the folks who have authored books on Perl or are at least (were) well known in the community.
It certainly was the major factor in how I connected the dots!
> Some of it I recognize as being an artefact of the time, when conciseness really mattered
It was an artefact of bursting out of those constraints, but honoring them still. The roots of perl as a “more capable, less restrictive” sed/awk means that it must support `perl -pi.bak -e oneliner file`, just like sed did — and so from that core requirement forward, everything it did, does. By the heyday of Perl5 era, conciseness was not a requirement, but the sed-compat roots remained a focus of the language’s creator.
It isn't bad language design that you need to study the language before you can use it. I look at haskell programs and it looks mysterious to me because I haven't spent any time studying it, but I'd not thing to say it is bad language design.
Yes, one can write obscure perl code and some love perl golfing. In the same way there is an IOCCC which delights in unreadable code, it doesn't mean that the C language should be relegated to the dustbin. The answer is to write readable code, no matter which language is in use.
Again: python syntax is more akin to what you are used to, and so it feels more comfortable to you.
$_ is inscrutable if you haven't studied perl, but the same thing would happen to anyone who sees a python decorator for the first time. what does "else: do after a while loop in python? Only people who know python know what it does (and I suspect most don't). The different quoting operators are also trivial to learn. In comparison, yield from python is also simple syntax but the semantics are much more involved.
BEGIN? Take 60 seconds to read what it means. And if you knew awk, you'd not have to do that, as it was directly lifted from awk.
Yeah, it's true that Perl did not have as a design goal that a complete newcomer should be able to intuitively understand the code without having any prior exposure to the language. There is a little bit of a learning curve, and that was completely expected by Perl's creators. Yes, you have to learn about the idioms above, but they became second-nature. For many of us, the model clicked in our heads and the terseness was worth it. You could express a lot of functionality in very few characters, and if you had invested in learning, it was very quick to grok because common patterns were reduced to familiar abstractions in the language.
And yet, as the industry grew and all sorts of people from all sorts of backgrounds converged in this space, the tolerance and appetite for funky/terse waned in favor of explicit/verbose/accessible. It's probably for the better in the end, but it did feel a little bit like the mom-and-pop store on the corner that had weird pickled things at the register and a meemaw in the back got replaced by a generic Circle K with a lesser soul.
Seems like the essential criteria is not whether you can write opaque code in it, but rather whether the language enables you to accomplish most tasks using clear, readable code. They aren't mutually exclusive.
Yup, Perl is something clearly out of Unseen University, err I mean Berkeley linguistics dept.
I liked it, thought the sigils were a cute way to singal that something is a variable. When you work with deeply nested data structures, dereferencing arrays and hashes that sort of changes and becomes kind of annoying. Nowadays I like Ruby. Compared to it, Perl does feel like spells mixed with C and Posix stuff. But if I want to feel smart, I'll write some code in Scheme, thank you.
The term "surrogate activity" comes to mind, specifically, activities of no real value that some people like to waste time on to feel better about themselves.
Perl made a mistake, the language was invested in depth of expression and that, in a programming language, just leads to a 1000 ways to write same thing where like... 2 of them are actually nice to read.
Pyton was ("was" was used here on purpose) the opposite, the whole "one way to do a thing" and insisting on more clean code even if more verbose.
You could write nice looking Perl code but you had to choose to do it, while Python pushed you in that direction from the start.
As much as I dislike using whitespace as flow control it also does make sure the code is always indented reasonably even if it is a newbie just starting in the language.
It didn't help that Perl, just like other languages after (PHP, JS, Python too), had a "curse of the newbie language", with many people starting with it (as at the time it was kinda only sensible choice for webpages before mod_php did a revolution in how most webpages are hosted), with no training and just winging it, which in language that puts no limits on what user can do and no guidance on what they should do... leads to that ugly one liners and line noise as a code scripts.
I don’t know about the wider Perl community, but I listened to some interviews from Larry Wall and he just came across as a nerdy guy having fun with what he’s doing. I quite liked listening to him.
Larry should be remembered for the development of "patch" more than perl. Without the concept of fuzzily applying patches to modified source files you can't have "git rebase" or "git merge".
Individuals are rarely (not never, but rarely) the full problem. Groups of people are what cause feedback loops and cultural reinforcement like the author describes. Sometimes this is a virtuous reinforcement cycle but more often than not the well gets poisoned over time.
My anecdotal experience was with perl guys who were ex-military, irreverent, and fly-by-the-seat-of-your-pants. The Java and .NET guys were straight laced and nerdy.
I actually think it works when you are in the ecosystem fulltime for a good while.
But having to interact with it once in a while is always a hurdle. The same with bash. Do I use [ or [[? Where does the semi-colon go? if then fi, but while do done (and not elihw). -eq or =? Functions have () but no parameters.
I'm sure those things make sense when all you write is Bash / Perl, but it's daunting.
Now, Python can get pretty far out there too with Meta-programming, and JavaScript can get confusing with prototyping. And Ruby (especially RoR) takes the crown, where they resolve variables at the moment the line executes. Makes debugging blocks really hard.
I never interacted with any of that, to me Perl was always "Bash with text processing built-in and no string interpolation pitfalls". I reach for it when I need to write one to two page long utility scripts. Python is too willing to deprecate features (plus the whole 2 to 3 fiasco burned me badly), so I only use it for things I know I will maintain. Perl is for writing a shell script that will run unchanged in perpetuity.
I appreciated them at the time I encountered them (mid-2000s), but they were definitely a bit cringe in their frequency and shamelessness. I wonder if younger people even know Monty Python anymore - by my time, I think people had mostly forgotten about Hitchhiker’s Guide to the Galaxy, even if 42 survived.
As a foreigner I hadn't known Monty Python when I started learning the language and reading the docs, and I haven't noticed any of those. I guess they came across as just noise.
I agree but don’t forget that the average programmer nowadays is a strait-laced corporate entity, whose personality is Node.js stickers on a macbook, like everybody else in their team.
They forget that Perl and co. were written by people that had one too many tabs of LSD in the 70s, sporting long hair and a ponytail.
Perl is a sysadmin language. There's "always" been this tension between sysadmins and developers.
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!
That quote is not very convincing to me. Both parts of it are questionable.
Just being able to play chess is not a very high bar at all. Most 6-year-olds can learn it in an hour. Are the Chess hustlers at Washington Square Park all Gentlemen?
I don't see being able to play Chess well as any kind of deficiency. It could be that it's just someone's hobby. It doesn't have to mean they spiraled into madness, Bobby Fisher style.
(I can play chess, but not well, so I personally don't care about either half of that quote as it applies to me)
I think Perl is still more popular even today than Python as a sysadmin language. Late 2000s it certainly was. Maybe Google was different, but across the industry more widely Python was barely used, Perl was used everywhere.
As someone who lived through that transition, we used Perl extensively to sysadmin ~30 Solaris and Irix workstations and it was superlative at that.
At that time, Guido was still working at CNRI locally to us in Reston, VA and we had several discussions at the local Pyggies (Python User Group) on transitioning over to Python for that work. We were a (mostly) C++/Java shop, but Perl fit into all the other "crevices" beautifully.
Python just didn't have enough library support for all of our "swiss-army chainsaw" demands. Still, it was very apparent at the time it would eventually get there and I was enamored with its "one right way" of doing things--even at the bytecode level.
I remember someone telling me to RTFM when I posted a question on IRC back in the 90s. Luckily, I explicitly asked if they were serious. They responded of course not-- they were kidding!
Then they PM'd me with hidden link that had an image map of Perl wizards with whom I could schedule a free meeting and coffee to get started as a newbie. I was skeptical-- who cares about some random noob from the interwebs?!? Well, Perl, apparently. That face-to-face meeting left me with goosebumps that I feel to this day when I think back on it. It turned out to be an important confidence booster and my chief way into programming.
I don't think it's an exaggeration to say that without Perl's focus on outreach I would never have served as president of Software Local 2142.
Like my wizard mentor told me when I tried to pay for the coffee that afternoon: Perl it forward!
In fairness, Perl died because it was just not a good language compared to others that popped up after its peak. Sometimes people just move to the better option.
Perl is a great language, the way Scala and Haskell are great: as openly experimental languages, they tried interesting, unorthodox approaches, with varied success. "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say.
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.
> "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say.
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. :)
Something I only figured out in the ‘10s is that the main tax of code smells is during debugging. Debugging when taken to the level of art is less about sorting all of the possible causes for a problem by likelihood but by ease of validation.
Things that are cheap to check should be checked first unless they are really unlikely. You change the numbers game from trying to make the biggest cleaving lines possible, to smaller bites that can be done rapidly (and perhaps more importantly, mentally cheaply).
Code smells chum the waters. Because where there is smoke sometimes there is fire, and code smells often hide bugs. You get into Tony Hoare’s Turing award speech; either no bugs are obvious, or there are no obvious bugs.
So I end up making the change easy and then making the easy change because we have more code each week so the existing code needs to be simpler if someone is going to continue to understand the entire thing.
Perl doesn’t seem to have figured this out at all.
Exactly. Perl is about experimenting, trying things your way, and discovering new and good ways to write programs. Which is a wonderful capability for research and discovery, and for art or recreation, but not that great for industrial production.
This is why Perl was quite fit for the job at the dawn, or, rather, the detonation phase of the Internet explosion in late 1980s and early 1990s, along with Lisp and Smalltalk that promote similar DIY wizardry values. But once the industry actually appeared and started to mature, more teamwork-friendly languages like Java, PHP, and Python started to take over.
I wouldn't say "wildly". I would say that it's critical enough to the company's workings that they devote enough resources to it to keep it going, but not enough resources to consider re-writing it or re-factoring it to be easier to work on.
Check out "Perl Best Practices" by Damien Conway, and the more recent "Modern Perl" by Chromatic. Both can be had as paperbacks, and I think both are also available free on online.
In a similar vein, as the industry matured, we went from having teams of wizards building products, to teams of "good-enough" developers, interchangeable, easy to onboard. Perl culture was too much about craft-mastery which ended up being at odds with most corporate cultures.
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.
The big pearl of wisdom I took from Larry Wall seemed to be counter to the culture I experienced looking in from the outside. That always confused me a bit about Perl.
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.
Couldn't they have figured out one decent way to do things before releasing features to all users? I tried Scala for a bit then decided it was complicated for no good reason.
Idk about Haskell, but I used Erlang which is also purely functional. No matter how long I used it and tried to appreciate its elegance, it became clear this isn't a convenient way to do things generally. But it was designed well, unlike Scala.
If you wanted to write a quick on off script then using magic variables,etc made sense. Writing something you’ll keep? Don’t use those. When Perl 5 introduced references they could have simplified the syntax though.
Erlang is, by my accounting, not even a functional langauge at all. It takes more than just having immutable values to be functional, and forcing users to leave varibles as immutable was a mistake, which Elixir fixes. Erlang code in practice is just imperative code written with immutable values, and like a lot of other modern languages, occasional callouts to things borrowed from functional programming like "map", but it is not a functional language in the modern sense.
If you go to learn Haskell, you will find that it has a lot to say about functional programming that Erlang did not teach you. You will also find that you've already gotten over one of the major hurdles to writing Haskell, which is writing with immutable values, which significantly reduces the difficult of swallowing the entire language at once and makes it relatively easier. I know it's a relatively easy path because it's the one I took.
Not really. It wasn’t audacious in service of anything innovative. Haskell takes functional programming to the nth degree, scala tried to be an advanced Java for example better at concurrency.
Perl was an early dynamic (garbage collected) “scripting language” but no more advanced than its contemporary python in this regard.
It had the weird sigils due to a poor design choice.
It had the many global cryptic variables and implicit variables due to a poor design choice.
It has the weird use of explicit references because of the bad design choice to flatten lists within lists to one giant list.
It actually was the one thing you said it wasn’t - a good practical general language at least within web and sysadmin worlds. At least until better competitors came along and built up library ecosystems.
I think what's most likely to happen here is that:
* a developer that knew how it worked used it in code where he *wanted* to get the first line
* someone just starting up copied it over and assumed that's the way to get the content of command into a variable
It's essentially complaining about using feature wrong on purpose, because the person that made mistake never learned the language.
my($var1, $var2...) is a way to multi-assign variables from an array.
and that makes perfect sense when you look at it. Perl have no multiple returns, but if you need a function that returns 2 variables it is very easy to make it work with:
my ($bandwidth, $latency) = speedtest($host)
Perl's feature for returning different type depending on caller is definitely a confusing part but
my @lines = `fortune`
returning lines makes perfect sense for the use case (you call external commands to parse its output, and if you do that you generally want it in lines, because then you can just do
foreach my $line (`fortune`) {}
and it "just works".
Now you might ask "why make such shortcuts?". Well, one of big mistakes when making Perl is that it was also aimed as replacement for sed/awk for the oneliners, so language is peppered with "clever short ways to do stuff", and it's a pleasure to use in quick ad-hoc oneliners for CLI.... but then people try to use same cleverness in the actual code and it ends up with the unreadable mess people know Perl for.
the fact you can do
my ($first_line, $second_line, ...) = `fortune`
is just the feature being.... consistent in its use "when you give it array, it will fill it with lines from the executed command"
you gave it array, and it just did what it does with arrays.
Then don't use the low level interfaces. In Perl, language features are plug and play. Everything's in a module. Use the core module List::Util instead.
That's not super subtle any more than it's super subtle that "*" performs multiplication and "+" performs addition. Sometimes you just need to learn the language.
This is not a general defense of Perl, which is many times absolutely unreadable, but this example is perfectly comprehensible if you actually are trying to write Perl and not superimpose some other language on it.*
It's just very non-obvious what the code does when you're skimming it.
Especially in a dynamic language like Perl, you wouldn't know that you're passing down an integer instead of a function until the code blows up in a completely unrelated function.
You can't do that if you gave up at the very first sigil puzzle.
I'm fine with that: to program in Perl you need to be able to follow manuals, man pages, expert answers, - and even perl cookbooks, or CPAN or web searches. It's a technical tool. The swiss army chainsaw. It's worth it.
Seems like you and a few other posters are making the article's point – that Perl's culture is hermetic and that new programmers would rather learn Python, Ruby or Javascript rather than figure out which sigil means what.
I wouldn't call it hermetic in that the many forms of documentation are insanely thorough and accessible - if not well advertised. There is no gate-keeping (from my point of view). New users are welcome. It's easy to learn (for the people for whom reading is not an obstacle).
But yes, no contest that the world has been on a simplicity binge. Python won by pushing simplicity and by having giant software corporations choosing it. If you want to go into programming professionally, for now many years, you need python.
I don't know that I would put Javascript in the same bag. I mean, it's the other way: it looks simple and it isn't.
But python, yes, python won because it looks simple and google pushed it.
Many other languages now have to reckon with the python supremacy. This is not specific to perl / raku. It will take work for anything to replace python.
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.
Shell had to do this because of shell reasons, like how you need spaces where you shouldn't. Perl post-dated C by over a decade, so there was no reason for goofy argument unpacking.
Perl was (and still is) a very expressive and concise language for working with text and a unix-style system. It exists in the odd space between a shell language and a general purpose language.
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)
> Perl was (and still is) a very expressive and concise language for working with text and a unix-style system. It exists in the odd space between a shell language and a general purpose language.
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.
Shell is a crappy scripting language because it has primitive data structures and data flow control making it hard to manage and manipulate data as you process it between applications. The fact that newlines are such a problem is a case in point.
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.
No. Perl died because other languages starting having an equivalent to CPAN and its extremely flexible syntax does not scale for medium to large team coordination.
It does if you restrict flexibility, but one of the critical flaws in Perl culture was the belief in letting everyone evolve in different directions while cooperating. It’s a genuinely charming belief, but it’s also explicitly incompatible with ‘interchangeable parts’ employment, and tends to only work in an environment where every individual is the ‘wizard’ lord of their personal domain over code. Even if you managed to train everyone to parse Perl, the cognitive overhead of having to train everyone in each other’s syntactic decisions was O(2^n) expensive, which contrasted quite sharply with Python moving that expensive cognitive overhead to the Proposals system while the produced language had slow version updates and “What we argued about so you don’t have to retread the same ground at work every quarter” mission briefs.
I was a fairly heavy user of Perl, but eventually migrated to Python. The primary reason was the generally abysmal quality of what was in CPAN compared to what was available as third-party packages for Python. I found myself having to spend way too much time fixing stuff I pulled down from CPAN far more than I'd need to for Python for the same functionality. Undoubtedly Perl stuff got better, but I didn't have time to wait.
I mainly moved on to Python because the startup time for scripts seemed to be a lot worse for Perl. I was a heavy Perl user in the 90's and early 2000's.
My first and only experience with Perl was like this: in 1997, just for fun, I tried to write a program in Perl to turn my Mozilla bookmarks into a website. After a week of not succeeding, in frustration I decided to try Python. In two days I had what I wanted, and programming it was a joy. That sealed my judgement that Perl (and all of its culture) was not for me, so I'm not surprised at all that others might feel the same.
(To be fair, there's a single oneliner that does make life a lot easier: ... | perl -pe 's{...}{...}')
> if difficulty itself becomes a badge of honour, you've created a trap: anything that makes the system more approachable starts to feel like it's cheapening what you achieved. You become invested in preserving the barriers you overcame.
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.
There was a lot of pressure in the Perl community to write things as succinctly as possible instead of as maintainably and understandably. That’s not realistic for use in a field with a lot of turnover and job hopping.
Write-only perhaps, but with perl you only have to write it once and it'll run forever, anywhere. No breaking on updates, no containers, no special version of Perl just for $application, just the system perl.
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.
Agreed! My father (RIP) absolutely loved Perl and could do amazing things with it in seemingly impossibly-few characters. I got reasonably proficient w/ regex but never came close to his wizardry. Much respect for those in his rarified company.
There was no such pressure. That's ridiculous. There were a lot of things people could grab as reasons to form an opinion without even reading articles, never mind the tutorial. They then ended up with php or python, even java for crying out loud, and years later THAT was a problem.
There wasn't pressure to write concise code exactly, but if you posted your code somewhere the odds were good that somebody would reply with a way to do the same thing with less code, followed by someone else who managed to shave several lines/characters off of that, etc.
While almost all of the time it was all just people having fun (perl is fun and play was encouraged) and not an admonishment of the code you'd posted or an example of how it should have been written I can see how some folks might have gotten that impression. Especially if they were new to perl and were more used to languages where TIMTOWTDI wasn't thing
I lived it. I'm sure there's still some Mailing List archives and IRC snippets that still endure, demonstrating the utter vicious 1-upmanship of how to do something in Perl as succinctly as possible. Why do X and Y when you can just do Z? What are you really trying to do? etc.
You COULD, if you wanted, and spent quite a bit of effort in the pursuit of that hobby, participate in one-liner, or obfuscation, or golfing friendly contests. Which were enabled by perl's expressiveness constructs. Nobody pushed anyone into that. On the contrary "there is more than one way to do it" was there to legitimize that getting the problem solved was the goal - instead of trying to force a one true way (like python).
After that, experts would often propose multiple ways to do something when they answered questions. THEY found that intellectually playful and exciting. They still do. And for the rest of us, that was an amazing way to learn more and understand more of that tool we were using daily. Still is.
You apparently saw viciousness in this and that certainly sucks.
Those experts were horrendously vicious. I can name them and can still describe their dismissive cruelty, since I spent ten years socializing nonstop in the Perl5 core communities (and have a CPAN id, and have an Authors entry in Perl5 core). Think “Linus before he learned to stop insulting people’s worth and focus on critiquing their work instead”. It was absolutely intended as a form of cultural propagation: I can do this more succinctly, so You Should Be Ashamed Before Me. If somehow you weren’t exposed to that aspect of it, I envy you.
Interestingly, that same prideful “my way is so obviously better that it’s a ridiculous waste of my time considering yours” ended up carrying forward to Mozilla, which was launched in part by cultural exports of the Perl5 conservative-libertarian community, and for a decade developer hiring was filtered for cultural sameness, leaving a forest of TMTOWTDI trees that viewed meadows as an aberration to be reforested back to their sameness.
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.
I had an interesting experience starting a job at ZipRecruiter, and finding that up to that point (2022), most of their code had been written in Perl. Their CTO had just gotten fed up with Perl and decreed that from now on, all new projects should be written in Go. I was the first one on my team to write code in Go.
There were various greybeards who kept telling me that Perl was a perfectly fine language and was fast enough for most purposes. I didn't argue with them and just backed away slowly.
Regarding Perl as a language, it seemed fine in the 1990s as a slightly more advanced alternative to Unix shells. But for me, what made it a failure as a language is that in order to have an array of hashes, or a hash of arrays, you needed to use references. That may have been a nice hack to enable some things in the 1990s, but even in 2005 that sounds pretty primitive and outdated to me. Plus the reliance on using magical variables consisting of $ and every non-letter ASCII character for all kinds of random stuff, like $_ and $# and so on. That may have been cool in 1992, but it's not 1992 any more.
Overall, Perl was pretty neat for little scripts up to 20 lines, but a bad idea for building an entire company on (like ZipRecruiter.) That's more of an indictment of ZipRecruiter than Perl.
> [TIMTOWTDI] literally means 'there is more than one way to do it in Perl' - and you can perhaps infer from that that there's little to no reason to do it using anything else
Not my experience at all, FWIW. For me, and the vast majority of Perl devs I’ve worked with over the past 30 years, TIMTOWTDI absolutely means some of the “ways to do it” don’t involve Perl, and that’s not only OK but expected. Of course Perl isn’t the be all/end all. It’s a lot of fun though!
(I’m a majority Perl coder to this day, it’s my favourite language by far. Hell, I even find it readable and easy/fun to debug)
I think a big part is does someone starting to program even hear that Perl exists? No, and they start learning python and so have little need to learn Perl after that
Which is (sadly) hilarious because that was the reason most people seem to have gone with python: they were told "this is what we use here" or they bought the "line noise" nonsense. They never put much effort into this.
But I also think that people who are truly interested in programming immediately learn that there are many different paradigms. And the net makes it dead easy for them to explore different directions and, I don't know, fall in love with haskell or something. Perl is plenty visible enough for THAT. I don't know about perl 6 / raku though.
That's why it has stayed dead. But that can't explain how it died. People don't just spontaneously stop hearing about the existence of a programming language in common use.
My client uses IBM servers with it’s hobbled version of Unix (AIX). Perl and access to copilot have really helped me out. I don’t love Perl but I’m damn glad I have acres to it.
Rather than its "decline was", Perl's existence is cultural. All programming languages (or any thought tools) are reflections and projections of the cognitive values of the community who creates and maintains them. In short, the Perl language shares the structure of the typical Perl dev's mind.
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.
The lede says Perl died because it was "reactionary" and "culturally conservative", but the content says Perl died because it had bad culture, the culture of angry, socially corrosive anonymous internet commenters.
If Perl had had a good culture, then conserving it would have been good!
Perl died for many reasons. For me, it was a language that was always too tempting to be too clever by half. I'd been using Perl pretty significantly from 1995-2000 (perl4 to perl5) when I was introduced to Python (1.5.2)[^1]. I greatly appreciated its simplicity, zen, batteries included standard lib, and REPL. I found add on packages easier to install than dealing with CPAN. I switched to Python and basically never looked back.
Perl is a very difficult language. PHP was a comparatively simple language. PHP was just a scripting language for C and incorporated as many open source C libraries as possible back when open source libraries were a bit of disjointed mess.
PHP's success and Perl's decline was obvious at the time.
I think PHP is way more accessible syntactically, even with all the standard complaints about the language. In the early 2000s it felt like "simple C style function calls embedded in HTML templates" more or less. Not much to have to teach there.
And serving it tends to be "copy the files to your web server's public dir".
There is no doubt that a product’s community culture and the maintainer’s attitude have a significant influence.
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
Perl 5's non-breaking conservatism kept old scripts running forever, but it also meant there was never a clear migration path the way Python 3 eventually provided, and that made long term planning a lot harder.
Though at the same time the bit where `use strict` was optional wound up being off-putting to a lot of us, at least in part because we'd always wind up with _something_ that wasn't designed for `use strict` and had, uh, interesting failure modes.
It's the same drive that we see from JS to TS these days, or adding type hints to Python, and even to some extent why people pick up Rust: because you get a refusal to act and an explanation rather than wonky results when you goof.
IME there's been a wider shift away from worse-is-better, and Perl was kind of one of the early casualties of that. Part of that is also how science has marched on: When Python and Perl were new, the most popular typed languages were kind of tedious but not what people would consider _good_ at types these days. Perl was the first language I learned, and if I was transported back to the 1990s, I'd probably still pick it, even if I don't use it in 2025.
(OK, maybe I'd go all in on OCaml. Any way the camel wins.)
I never really warmed to perl in its era but perl dbi was kind of perfect in its way. If you needed what it could do, it got very intuitive very fast, and was pretty terse. Both of which were supposedly the appeal of perl.
I didn't like cpan and python was just easier and available, if python didn't exist I'd like to think I'd have invested heavily in perl because it was everywhere at some point.
The number of blogs posted on here by people who can’t be arsed to make their writing legible on mobile blows my mind. Did everybody just skip the section of their CSS journey that covered media queries or what?
I enjoyed the article but it was a nightmare to read on my phone’s browser
I'd take this a step further and say that the design flaws that motivated Perl6 were what really killed Perl. Perl6 just accelerated the timeline.
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.
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.
It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode.
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.
> It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode.
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.
With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade.
Imagine if the same interpreter supported both Python 3 and Python 2. Python 3 code could import a Python 2 module, or vice versa. Codebases could migrate somewhat more incrementally. Python 2 code's idea of a "string" would be bytes, and python 3's idea of a "string" would be unicode, but both can speak the other's language, they just have different names for things, so you can migrate.
It would absolutely have been harder. But the pain of going that path might potentially have been less than the pain of the Python 2 to Python 3 transition. Or, possibly, it wouldn't have been; I'm not claiming the tradeoff is obvious even in hindsight here.
> Perl always had a significant amount of what you might call "BOFH" culture, which came from its old UNIX sysadmin roots. All of those passive aggressive idioms and in jokes like "RTFM", "lusers", "wizards", "asking for help the wrong way" etc.
> [...]
> Cultural conservatism as a first principle.
Counterpoint to this: Rust. Rust has a similar RTFM/"wizards" culture, but is not culturally conservative (in any sense of the word).
My two cents: Perl's "culture" had little to do with its fall. I think Perl's problems run much deeper. Perl is built on rotten foundations. It's fundamentally a scripting language (albeit with bolted on additions to make it kinda-OOP), and it therefore has all the problems that scripting languages have for building large software projects.
Those problems have no quick fix, and indeed fixing them would require throwing the language out entirely -- at which point, why not simply switch to another language entirely (which is exactly what happened...).
Probably stretching the cultural metaphor too far here, but Rust has much more of a “vanguard of the proletariat” vibe & appears susceptible to some of the problems inherent in that political mission.
"Willing" is an interesting word choice. There was quite a bit of resistance in the Python world despite the clear benefits. (2.x really could not be fixed, because the semantics were fundamentally broken in many places.)
I looked at Perl once and decided to just not use it, and hoped it'd go away so I never have to use it. Sorry, the decline was probably due to it being bad.
Perl being so old means it's extremely fast for what it's designed to do, process streams or pipes. In a few tasks, it's faster than C, but being much faster to create a script or program that is useful, and with the implicit syntactic sugar, and since it's so flexible, you can just do things in the one way you know how and that's usually good enough.
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.
Perl is amazing when it comes to regular expressions too. It's one of the reasons why perl is way more fun to write than Python. I still use perl for regex heavy tasks. I wish that python had integrated regex into the language the same way.
I worked for a few years in an large org which utilized perl for build scripts, testing automation, and a few other things. I would summarize the half decade Perl learning curve as initial bewilderment, intermediate cult like praise, to advance level disillusionment.
There was something about scaling usage in large teams that felt awkward and high friction.
I spent year developing CMS in Perl in 1999 (HTA application with ActivePerl. wonder if anybody else did something like this). It traumatized me, and first thing that I did in my next job is to learn python and develop some core systems in it. Few of my friends moved from perl to python as well.
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
Before I eventually switched to PHP, I ended up writing multiple CMS-like solutions that would run via `cgi-bin` but write contents to the webroot (what we would now call a static site generator). As I was quite limited with the standard shared hosting at the time, I ended up inventing my own single file database format (it was a simple text file) to keep state. It worked quite beautifully and kept me afloat for the first few years of my life as a web developer around the early 2000s.
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.
I wrote php2 + msql before starting in that company (and a bit of php3). Like in your case it was essentially static site generator but the management part was HTA (application hosted in internet explorer. you could write one using whatever activex/language: vbscript, python, perl).
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)
Perl heads are downvoting you but I agree as a longtime ex Perl user that the sigils were noisy nonsense.
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.
Oops last example should be $hash1->{“hash2”} - this is a whole hash referenced with $ because of the implementation detail that it is in hash1 as a reference, which is considered a scalar.
Technically you are allowed to use % like so: %{$hash1->{“hash2”}}. Which, just - lol.
Before that job in perl i wrote asm/tcl/delphi/c/php (and bunch of other languages after).
This perl syntax caused some kind of rejection on almost physical level. It was same for many of my friends. "Zen of python" was a breath of fresh air.
Perl was of a time, so it's important to remember when it was around. CPAN was legitimately one of the first package managers for a programming language that WORKED. Contextually, its references are bash, sed, awk, and other cli tools. There are too many ways to do things in perl because of the various flavors / takes on how to do things. It was also a fun way to write cgi apps in the era of C/C++. Is that the best way to do things today? No! It was one way to do something complex in few lines of code. It was the python of its day in many ways.
There are tons of quirks that are interesting that influenced language development today, for me the spaceship operator "<=>" was a fun one. You can have a flip through the camel book to see what kind of stunts were common in its era.
It is an auteur language that was not really done the way languages are today.
Perl 6 did massive damage to the community mainly because it was so different that it looked like a fantasy language. That along with Parrot really lost the plot for me, I had mostly stopped doing that kind of work and moved on to R for my bioinformatics things. Bioconductor was the bees knees.
I'm surprised at all the haterade, probably you're either <30, and/or being overly critical of a very nascent tech era. Perl was pre and post .bomb, and had one of the first online communities that I remember that shared tips and tricks at scale at perlmonks.org. It predated stackoverflow! It was a very different time to now.
This was also from a time when people still paid for compilers(!)
I am deeply biased, as I wrote a 3d distance calculator in Perl for small molecule drugs. We were looking for disulfiram analogs doing biopanning and then simulations. There was a great PDB library for structures at that time that saved me tons of time. This was circa 2005~, ages from now.
Ironically alluding to the possibility of others who would castigate you for saying something reasonable things, is not any less obnoxious than the castigation.
C'mon. The language was like something born in Hogwart's. Magic spells, incantations. It lost because it was not an easy language to learn - and others were (in particular Python) - while being just as powerful.
I don't get why Ruby is mentioned before PHP. The only Ruby thing I've ever come across is GitLab, and not with positive associations either - up until maybe 3, 4 years ago particularly Sidekiq was a constant point of utter pain.
I was surprised by that, too, and assumed it was a decade-old article until I saw the date at the bottom. Both being mentioned before Python is wilder, as is the total exclusion of JavaScript.
JavaScript on the backend is a rare thing to see, even in "resume driven development" scenarios it's usually some sort of static build that gets pushed to S3 or whatever.
Node.js is the most popular web framework/technology in the StackOverflow developer survey. Express is more popular than FastAPI, Django, Flask and Rails in the same survey. Just... what are you talking about?
i disagree, python is Just Better. ive never used perl but ive had to install it due to some antique tools requiring it, and every time its been an incomprehensible mess. i still have no idea how packages work in perl. also, it seems like everything in perl is a string? and the syntax looks like a mess.
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's "decline" saved it from a fate worst than death: popularity and splitting into dozens of incompatible versions from added/removed features (like python). Instead Perl is just available everywhere in the same stable form. Scripts always can just use the system perl interpreter. And most of the time a script written in $currentyear can run just as well on a perl system interpreter from 2 decades ago (and vice versa). It is the perfect language for system adminstration and personal use. Even if it isn't for machine learning and those kinds of bleeding edge things that need constant major changes. There are trade-offs.
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.
Perl's binary brings with it the ability to run every release of the language, from 5.8 onwards. You can mix and match Perl 5.30 code with 5.8 code with 5.20 code, whatever, just say "use v5.20.0;" at the start of each module or script.
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.
> By comparison, Python can barely go one version without both introducing new things and removing old things from the language
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:
$ py2.7
Python 2.7.18 (default, Feb 20 2025, 09:47:11)
[GCC 13.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print('foo', 'bar')
('foo', 'bar')
>>> print 'foo', 'bar'
foo bar
The incompatible bytes/string handling is also a fundamental shift. You would at least need a pragma.
What incompatible versions of pythons do you mean? I'm entirely unaware of any forks, and the youngest version I have to supply at the moment is 3.9, which is over 5 years old and available in all supported platforms.
Try to run any random python program of moderate dep use on your python 3.9 system interpreter without using containers. Most likely you'll have to use a venv or the like and setup a special version of python just for that application. It's the standard now because system Python can't do it. In practice, pragmatically, there is no Python. Only pythons. And that's not even getting in to the major breakages in point version upgrades or the whole python 2 to 3 language switch.
> Most likely you'll have to use a venv or the like and setup a special version of python just for that application.
Using venvs is trivial (and orders of magnitude more lightweight than a container). And virtually every popular package has a policy of supporting at least all currently supported Python versions with each new release.
You need to set up a venv because of how the language is designed, and how it has always worked since the beginning. Python doesn't accommodate multiple versions of a package in the same runtime environment, full stop. The syntax doesn't provide for version numbers on imports. Imports are cached by symbolic name and everyone is explicitly expected to rely on this for program correctness (i.e., your library can have global state and the client will get a singleton module object). People just didn't notice/care because the entire "ecosystem" concept didn't exist yet.
I have at least one local from-source build of every Python from 3.3-3.14 inclusive (plus 2.7); it's easy to do. But I have them explicitly for testing, not because using someone else's project forces me to. The ecosystem is just not like that unless perhaps you are specifically using some sort of PyTorch/CUDA/Tensorflow related stack.
> It's the standard now because system Python can't do it.
Your system Python absolutely can have packages installed into it. The restrictions are because your Linux distro wants to be able to manage the system environment. The system package manager shouldn't have to grok files that it didn't put there, and system tools shouldn't have to risk picking up a dependency you put there. Please read https://peps.python.org/pep-0668/, especially the motivation and rationale sections.
> major breakages in point version upgrades
I can think of exactly one (`async` becoming a keyword, breaking Tensorflow that was using it as a parameter name). And they responded to that by introducing the concept of soft keywords. Beyond that, it's just not a thing for your code to become syntactically invalid or to change in semantics because of a 3.x point version change. It's just the standard library that has changes or removals. You can trivially fix this by vendoring the old code.
How old are you now? Mid fifties here. And 'vibe coding' in what exactly - it is not of interest from a programming perspective, but from a 'what does the AI know best perspective'? I've followed a similar, but not identical trajectory and now vibe in python/htmx/flask without needing to review the code in depth (NB internal apps, not public facing ones), with claude code max. Vibe coding in the last 6-8 weeks now also seems to make a decent fist of embedded coding - esp32/arduino/esp-32, also claude code.
I always found the Perl "community" to be really off-putting with all the monk and wizard nonsense. Then there was the whole one-liner thing that was all about being clever and obscure. Everything about Python came off as being much more serious and normal for a young nerd who wasn't a theater kid.
I'm having to pick up some perl now, and while I don't interact with the community, it surely _feels_ like it was written by wizards, for wizards. Obscure, non-intuitive oneliners, syntax that feels like it was intentionally written to be complicated, and a few other things that feel impossible to understand without reading the docs. (Before everyone jumps on me - yes, as a developer, I should be able to read documentation. And I did. But until I did so, what the code was doing was completely opaque to me. That feels like bad language design.)
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.
It’s interesting to me how brains work.
Perl has always “flowed” for me and made mostly intuitive sense. Every other language I’ve had to hack on to get something done is a struggle for me to fit into some rigid-feeling mental box.
I understand I’m the weird one, but man I miss Perl being an acceptable language to pound out a quick program in between “bash script” and “real developer”.
Was Perl one of your first languages by any chance? I freely admit that I've only been poking at it for a few months; maybe by this time next year, I'll be boggled at the comment I left, like it was written by a different person.
> in between “bash script” and “real developer”.
One of my coworkers gave me some great perspective by saying, "at least it's not written in Bash!"
Yep, first language I learned. And since I was somewhat early to the Internet thing, I found IRC when I was about 14 years old and actually learned from a lot of the folks who have authored books on Perl or are at least (were) well known in the community.
It certainly was the major factor in how I connected the dots!
> Some of it I recognize as being an artefact of the time, when conciseness really mattered
It was an artefact of bursting out of those constraints, but honoring them still. The roots of perl as a “more capable, less restrictive” sed/awk means that it must support `perl -pi.bak -e oneliner file`, just like sed did — and so from that core requirement forward, everything it did, does. By the heyday of Perl5 era, conciseness was not a requirement, but the sed-compat roots remained a focus of the language’s creator.
It isn't bad language design that you need to study the language before you can use it. I look at haskell programs and it looks mysterious to me because I haven't spent any time studying it, but I'd not thing to say it is bad language design.
Yes, one can write obscure perl code and some love perl golfing. In the same way there is an IOCCC which delights in unreadable code, it doesn't mean that the C language should be relegated to the dustbin. The answer is to write readable code, no matter which language is in use.
But I can look at most Python code and be able to understand what it does. With perl, I have to look up so much.
- Why is there a `1;` on a single line in the middle of this file?
- What is `$_`?
- This parallel execution manager doesn't actually seem to define what code needs to run in parallel in any specific way, how does this work?
- What is this BEGIN block at the start of this Perl file? Why is that necessary?
- What's going on with qx, qw, qq?
- What does chomp do when it's just on its own line, with no arguments given to it?
Again: python syntax is more akin to what you are used to, and so it feels more comfortable to you.
$_ is inscrutable if you haven't studied perl, but the same thing would happen to anyone who sees a python decorator for the first time. what does "else: do after a while loop in python? Only people who know python know what it does (and I suspect most don't). The different quoting operators are also trivial to learn. In comparison, yield from python is also simple syntax but the semantics are much more involved.
BEGIN? Take 60 seconds to read what it means. And if you knew awk, you'd not have to do that, as it was directly lifted from awk.
Yeah, it's true that Perl did not have as a design goal that a complete newcomer should be able to intuitively understand the code without having any prior exposure to the language. There is a little bit of a learning curve, and that was completely expected by Perl's creators. Yes, you have to learn about the idioms above, but they became second-nature. For many of us, the model clicked in our heads and the terseness was worth it. You could express a lot of functionality in very few characters, and if you had invested in learning, it was very quick to grok because common patterns were reduced to familiar abstractions in the language.
And yet, as the industry grew and all sorts of people from all sorts of backgrounds converged in this space, the tolerance and appetite for funky/terse waned in favor of explicit/verbose/accessible. It's probably for the better in the end, but it did feel a little bit like the mom-and-pop store on the corner that had weird pickled things at the register and a meemaw in the back got replaced by a generic Circle K with a lesser soul.
Seems like the essential criteria is not whether you can write opaque code in it, but rather whether the language enables you to accomplish most tasks using clear, readable code. They aren't mutually exclusive.
Hopefully I am paraphrasing you correctly.
Yup, Perl is something clearly out of Unseen University, err I mean Berkeley linguistics dept.
I liked it, thought the sigils were a cute way to singal that something is a variable. When you work with deeply nested data structures, dereferencing arrays and hashes that sort of changes and becomes kind of annoying. Nowadays I like Ruby. Compared to it, Perl does feel like spells mixed with C and Posix stuff. But if I want to feel smart, I'll write some code in Scheme, thank you.
The term "surrogate activity" comes to mind, specifically, activities of no real value that some people like to waste time on to feel better about themselves.
Perl made a mistake, the language was invested in depth of expression and that, in a programming language, just leads to a 1000 ways to write same thing where like... 2 of them are actually nice to read.
Pyton was ("was" was used here on purpose) the opposite, the whole "one way to do a thing" and insisting on more clean code even if more verbose.
You could write nice looking Perl code but you had to choose to do it, while Python pushed you in that direction from the start.
As much as I dislike using whitespace as flow control it also does make sure the code is always indented reasonably even if it is a newbie just starting in the language.
It didn't help that Perl, just like other languages after (PHP, JS, Python too), had a "curse of the newbie language", with many people starting with it (as at the time it was kinda only sensible choice for webpages before mod_php did a revolution in how most webpages are hosted), with no training and just winging it, which in language that puts no limits on what user can do and no guidance on what they should do... leads to that ugly one liners and line noise as a code scripts.
The syntax problems are just surface. There are some real problems underneath:
Poor performance of the single implementation.
A single implementation.
Leaky ref counted GC, but 'luckily' the syntax for references is so clunky that nobody does anything complicated enough that it really matters.
Bolted on object oriented features that never got the love they needed at a time when oo languages were sweeping the world.
Most of the wizards decamping to a new language (Perl6) that was 'developed' for years without an actual implementation to keep them grounded.
I don’t know about the wider Perl community, but I listened to some interviews from Larry Wall and he just came across as a nerdy guy having fun with what he’s doing. I quite liked listening to him.
Larry should be remembered for the development of "patch" more than perl. Without the concept of fuzzily applying patches to modified source files you can't have "git rebase" or "git merge".
I was never a perl programmer, but this was my impression of basically every perl programmer I have interacted with.
Also, I think Larry Wall's "Diligence, Patience, Humility"[0] is among my favourite articles about programming.
[0] https://www.oreilly.com/openbook/opensources/book/larry.html
Individuals are rarely (not never, but rarely) the full problem. Groups of people are what cause feedback loops and cultural reinforcement like the author describes. Sometimes this is a virtuous reinforcement cycle but more often than not the well gets poisoned over time.
My anecdotal experience was with perl guys who were ex-military, irreverent, and fly-by-the-seat-of-your-pants. The Java and .NET guys were straight laced and nerdy.
I actually think it works when you are in the ecosystem fulltime for a good while.
But having to interact with it once in a while is always a hurdle. The same with bash. Do I use [ or [[? Where does the semi-colon go? if then fi, but while do done (and not elihw). -eq or =? Functions have () but no parameters.
I'm sure those things make sense when all you write is Bash / Perl, but it's daunting.
Now, Python can get pretty far out there too with Meta-programming, and JavaScript can get confusing with prototyping. And Ruby (especially RoR) takes the crown, where they resolve variables at the moment the line executes. Makes debugging blocks really hard.
The less magic in code the better.
I never interacted with any of that, to me Perl was always "Bash with text processing built-in and no string interpolation pitfalls". I reach for it when I need to write one to two page long utility scripts. Python is too willing to deprecate features (plus the whole 2 to 3 fiasco burned me badly), so I only use it for things I know I will maintain. Perl is for writing a shell script that will run unchanged in perpetuity.
This made me smile given Python's love of Monty Python references - the cheese shop etc.
I appreciated them at the time I encountered them (mid-2000s), but they were definitely a bit cringe in their frequency and shamelessness. I wonder if younger people even know Monty Python anymore - by my time, I think people had mostly forgotten about Hitchhiker’s Guide to the Galaxy, even if 42 survived.
As a foreigner I hadn't known Monty Python when I started learning the language and reading the docs, and I haven't noticed any of those. I guess they came across as just noise.
The kids these days have factored 42 to 6,7 (said with some inflection and hand waving)
Did you come up with that? If so, bravo!
Dude it is not cringe. It is silly.
Pretending to be a all serius grown ups language is cringe.
I agree but don’t forget that the average programmer nowadays is a strait-laced corporate entity, whose personality is Node.js stickers on a macbook, like everybody else in their team.
They forget that Perl and co. were written by people that had one too many tabs of LSD in the 70s, sporting long hair and a ponytail.
Perl is a sysadmin language. There's "always" been this tension between sysadmins and developers.
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!
> some kind of inferiority complex meant to preserve the self image
Or, as the kids say, a flex, but without the sexy connotations.
(Incidentally, I am also reminded of a great quote attributed to Morphy:
"The ability to play chess is the sign of a gentleman. The ability to play chess well is the sign of a wasted life.")
That quote is not very convincing to me. Both parts of it are questionable.
Just being able to play chess is not a very high bar at all. Most 6-year-olds can learn it in an hour. Are the Chess hustlers at Washington Square Park all Gentlemen?
I don't see being able to play Chess well as any kind of deficiency. It could be that it's just someone's hobby. It doesn't have to mean they spiraled into madness, Bobby Fisher style.
(I can play chess, but not well, so I personally don't care about either half of that quote as it applies to me)
In the 2000’s Python was also a sysadmin language.
Edit: But I see your point, Google SRE’s around the late 2000’s reached for Python more than Perl.
I think Perl is still more popular even today than Python as a sysadmin language. Late 2000s it certainly was. Maybe Google was different, but across the industry more widely Python was barely used, Perl was used everywhere.
My experience:
Sysadmin-driven companies (typically Sun-based) often used Perl.
Developer-driven companies used other languages running on cheaper X86 Linux.
(90s) Yes, but it developed.
As someone who lived through that transition, we used Perl extensively to sysadmin ~30 Solaris and Irix workstations and it was superlative at that.
At that time, Guido was still working at CNRI locally to us in Reston, VA and we had several discussions at the local Pyggies (Python User Group) on transitioning over to Python for that work. We were a (mostly) C++/Java shop, but Perl fit into all the other "crevices" beautifully.
Python just didn't have enough library support for all of our "swiss-army chainsaw" demands. Still, it was very apparent at the time it would eventually get there and I was enamored with its "one right way" of doing things--even at the bytecode level.
> None of this is literally serious,
Exactly.
I remember someone telling me to RTFM when I posted a question on IRC back in the 90s. Luckily, I explicitly asked if they were serious. They responded of course not-- they were kidding!
Then they PM'd me with hidden link that had an image map of Perl wizards with whom I could schedule a free meeting and coffee to get started as a newbie. I was skeptical-- who cares about some random noob from the interwebs?!? Well, Perl, apparently. That face-to-face meeting left me with goosebumps that I feel to this day when I think back on it. It turned out to be an important confidence booster and my chief way into programming.
I don't think it's an exaggeration to say that without Perl's focus on outreach I would never have served as president of Software Local 2142.
Like my wizard mentor told me when I tried to pay for the coffee that afternoon: Perl it forward!
I need to hear more about this Software Local 2142.
In fairness, Perl died because it was just not a good language compared to others that popped up after its peak. Sometimes people just move to the better option.
Perl is a great language, the way Scala and Haskell are great: as openly experimental languages, they tried interesting, unorthodox approaches, with varied success. "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say.
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.
> "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say.
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. :)
Something I only figured out in the ‘10s is that the main tax of code smells is during debugging. Debugging when taken to the level of art is less about sorting all of the possible causes for a problem by likelihood but by ease of validation.
Things that are cheap to check should be checked first unless they are really unlikely. You change the numbers game from trying to make the biggest cleaving lines possible, to smaller bites that can be done rapidly (and perhaps more importantly, mentally cheaply).
Code smells chum the waters. Because where there is smoke sometimes there is fire, and code smells often hide bugs. You get into Tony Hoare’s Turing award speech; either no bugs are obvious, or there are no obvious bugs.
So I end up making the change easy and then making the easy change because we have more code each week so the existing code needs to be simpler if someone is going to continue to understand the entire thing.
Perl doesn’t seem to have figured this out at all.
Exactly. Perl is about experimenting, trying things your way, and discovering new and good ways to write programs. Which is a wonderful capability for research and discovery, and for art or recreation, but not that great for industrial production.
This is why Perl was quite fit for the job at the dawn, or, rather, the detonation phase of the Internet explosion in late 1980s and early 1990s, along with Lisp and Smalltalk that promote similar DIY wizardry values. But once the industry actually appeared and started to mature, more teamwork-friendly languages like Java, PHP, and Python started to take over.
> in 2026, it'll be 11 developers writing it over 11 years.
Perhaps too, a tool that's been around and in active maintenance for 11 years has been wildly successful.
I wouldn't say "wildly". I would say that it's critical enough to the company's workings that they devote enough resources to it to keep it going, but not enough resources to consider re-writing it or re-factoring it to be easier to work on.
It could have used a good "Perl: the Good Parts" book.
With a team where everybody wrote it in a similar style, Perl did perfectly well. Mod_perl was fast. I liked Perl.
Then Django came out, and then Numpy, and Perl lost. But Python is still so incredibly slow....
Check out "Perl Best Practices" by Damien Conway, and the more recent "Modern Perl" by Chromatic. Both can be had as paperbacks, and I think both are also available free on online.
Mostly - from here - python is so incredibly slow to write. Who has this kind of time?
Slow to write, slow to run and throws whitespace errors. Surprised it made it so far.
Sounds exactly like academia itself, and is probably a selling point if you’re a business.
In a similar vein, as the industry matured, we went from having teams of wizards building products, to teams of "good-enough" developers, interchangeable, easy to onboard. Perl culture was too much about craft-mastery which ended up being at odds with most corporate cultures.
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.
The big pearl of wisdom I took from Larry Wall seemed to be counter to the culture I experienced looking in from the outside. That always confused me a bit about Perl.
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.
It is not a great language.
It is, however, a significant language. It has left a mark and influence on the culture and industry of programming. Nothing to sneeze at.
Couldn't they have figured out one decent way to do things before releasing features to all users? I tried Scala for a bit then decided it was complicated for no good reason.
Idk about Haskell, but I used Erlang which is also purely functional. No matter how long I used it and tried to appreciate its elegance, it became clear this isn't a convenient way to do things generally. But it was designed well, unlike Scala.
If you wanted to write a quick on off script then using magic variables,etc made sense. Writing something you’ll keep? Don’t use those. When Perl 5 introduced references they could have simplified the syntax though.
Erlang is, by my accounting, not even a functional langauge at all. It takes more than just having immutable values to be functional, and forcing users to leave varibles as immutable was a mistake, which Elixir fixes. Erlang code in practice is just imperative code written with immutable values, and like a lot of other modern languages, occasional callouts to things borrowed from functional programming like "map", but it is not a functional language in the modern sense.
If you go to learn Haskell, you will find that it has a lot to say about functional programming that Erlang did not teach you. You will also find that you've already gotten over one of the major hurdles to writing Haskell, which is writing with immutable values, which significantly reduces the difficult of swallowing the entire language at once and makes it relatively easier. I know it's a relatively easy path because it's the one I took.
Not really. It wasn’t audacious in service of anything innovative. Haskell takes functional programming to the nth degree, scala tried to be an advanced Java for example better at concurrency.
Perl was an early dynamic (garbage collected) “scripting language” but no more advanced than its contemporary python in this regard.
It had the weird sigils due to a poor design choice.
It had the many global cryptic variables and implicit variables due to a poor design choice.
It has the weird use of explicit references because of the bad design choice to flatten lists within lists to one giant list.
It actually was the one thing you said it wasn’t - a good practical general language at least within web and sysadmin worlds. At least until better competitors came along and built up library ecosystems.
There was so much complexity hidden behind "do what I mean". For example, scalar vs array context which was super subtle:
Or even worse:
Which allegedly got a HS kid in hot water[^1].[^1]: "It's all about context" (2001): https://archive.ph/IB2kR (http://www.stonehenge.com/merlyn/UnixReview/col38.html)
I think what's most likely to happen here is that: * a developer that knew how it worked used it in code where he *wanted* to get the first line * someone just starting up copied it over and assumed that's the way to get the content of command into a variable
It's essentially complaining about using feature wrong on purpose, because the person that made mistake never learned the language.
my($var1, $var2...) is a way to multi-assign variables from an array.
and that makes perfect sense when you look at it. Perl have no multiple returns, but if you need a function that returns 2 variables it is very easy to make it work with:
Perl's feature for returning different type depending on caller is definitely a confusing part but returning lines makes perfect sense for the use case (you call external commands to parse its output, and if you do that you generally want it in lines, because then you can just do and it "just works".Now you might ask "why make such shortcuts?". Well, one of big mistakes when making Perl is that it was also aimed as replacement for sed/awk for the oneliners, so language is peppered with "clever short ways to do stuff", and it's a pleasure to use in quick ad-hoc oneliners for CLI.... but then people try to use same cleverness in the actual code and it ends up with the unreadable mess people know Perl for.
the fact you can do
is just the feature being.... consistent in its use "when you give it array, it will fill it with lines from the executed command"you gave it array, and it just did what it does with arrays.
Then don't use the low level interfaces. In Perl, language features are plug and play. Everything's in a module. Use the core module List::Util instead.
That's not super subtle any more than it's super subtle that "*" performs multiplication and "+" performs addition. Sometimes you just need to learn the language.
This is not a general defense of Perl, which is many times absolutely unreadable, but this example is perfectly comprehensible if you actually are trying to write Perl and not superimpose some other language on it.*
What exactly is complex or "super subtle" about this? It's the textbook example from the 1st chapter in the tutorial or something?
It's just very non-obvious what the code does when you're skimming it.
Especially in a dynamic language like Perl, you wouldn't know that you're passing down an integer instead of a function until the code blows up in a completely unrelated function.
Then use one of the type systems for Perl.
https://metacpan.org/pod/Type::Tiny
You can't do that if you gave up at the very first sigil puzzle.
I'm fine with that: to program in Perl you need to be able to follow manuals, man pages, expert answers, - and even perl cookbooks, or CPAN or web searches. It's a technical tool. The swiss army chainsaw. It's worth it.
Seems like you and a few other posters are making the article's point – that Perl's culture is hermetic and that new programmers would rather learn Python, Ruby or Javascript rather than figure out which sigil means what.
I wouldn't call it hermetic in that the many forms of documentation are insanely thorough and accessible - if not well advertised. There is no gate-keeping (from my point of view). New users are welcome. It's easy to learn (for the people for whom reading is not an obstacle).
But yes, no contest that the world has been on a simplicity binge. Python won by pushing simplicity and by having giant software corporations choosing it. If you want to go into programming professionally, for now many years, you need python.
I don't know that I would put Javascript in the same bag. I mean, it's the other way: it looks simple and it isn't.
But python, yes, python won because it looks simple and google pushed it.
Many other languages now have to reckon with the python supremacy. This is not specific to perl / raku. It will take work for anything to replace python.
I always found contextual eval interesting. It's a generalized version of toString in a way
It's not complexity, it's magic. Useful when one cannot be bothered to write array.length. So is if (@a) when the array is empty.
Yeah I think I would have been considered part of the “in” crowd of Perl to some degree and it wasn’t the culture that drove me away and to Python.
It was Django and the people involved with it.
> and the people involved with it.
Culture?
I agree and Steve Yegge covered the reasons well here: https://sites.google.com/site/steveyegge2/ancient-languages-...
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.
> bolted on, awkward params passing
Shell had to do this because of shell reasons, like how you need spaces where you shouldn't. Perl post-dated C by over a decade, so there was no reason for goofy argument unpacking.
Perl was (and still is) a very expressive and concise language for working with text and a unix-style system. It exists in the odd space between a shell language and a general purpose language.
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)
> Perl was (and still is) a very expressive and concise language for working with text and a unix-style system. It exists in the odd space between a shell language and a general purpose language.
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.
Shell is a crappy scripting language because it has primitive data structures and data flow control making it hard to manage and manipulate data as you process it between applications. The fact that newlines are such a problem is a case in point.
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.
I assume you refer to https://www.pyinvoke.org/ which I just looked up. It looks quite promising, thanks for the heads-up.
> Perl was (and still is) a very expressive and concise language
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.
No. Perl died because other languages starting having an equivalent to CPAN and its extremely flexible syntax does not scale for medium to large team coordination.
It does if you restrict flexibility, but one of the critical flaws in Perl culture was the belief in letting everyone evolve in different directions while cooperating. It’s a genuinely charming belief, but it’s also explicitly incompatible with ‘interchangeable parts’ employment, and tends to only work in an environment where every individual is the ‘wizard’ lord of their personal domain over code. Even if you managed to train everyone to parse Perl, the cognitive overhead of having to train everyone in each other’s syntactic decisions was O(2^n) expensive, which contrasted quite sharply with Python moving that expensive cognitive overhead to the Proposals system while the produced language had slow version updates and “What we argued about so you don’t have to retread the same ground at work every quarter” mission briefs.
I was a fairly heavy user of Perl, but eventually migrated to Python. The primary reason was the generally abysmal quality of what was in CPAN compared to what was available as third-party packages for Python. I found myself having to spend way too much time fixing stuff I pulled down from CPAN far more than I'd need to for Python for the same functionality. Undoubtedly Perl stuff got better, but I didn't have time to wait.
I mainly moved on to Python because the startup time for scripts seemed to be a lot worse for Perl. I was a heavy Perl user in the 90's and early 2000's.
My first and only experience with Perl was like this: in 1997, just for fun, I tried to write a program in Perl to turn my Mozilla bookmarks into a website. After a week of not succeeding, in frustration I decided to try Python. In two days I had what I wanted, and programming it was a joy. That sealed my judgement that Perl (and all of its culture) was not for me, so I'm not surprised at all that others might feel the same. (To be fair, there's a single oneliner that does make life a lot easier: ... | perl -pe 's{...}{...}')
> if difficulty itself becomes a badge of honour, you've created a trap: anything that makes the system more approachable starts to feel like it's cheapening what you achieved. You become invested in preserving the barriers you overcame.
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.
There was a lot of pressure in the Perl community to write things as succinctly as possible instead of as maintainably and understandably. That’s not realistic for use in a field with a lot of turnover and job hopping.
Yeah the joke was, Perl is write-only.
Write-only perhaps, but with perl you only have to write it once and it'll run forever, anywhere. No breaking on updates, no containers, no special version of Perl just for $application, just the system perl.
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.
Aren't perl modules locked to the exact version they were compiled in ?
I've met many time some error "haha nope, wrong version, perl 5.31.7 required"
There was really only one big forced rewrite, 2->3, and ironically Perl was killed by failure to do the same with 5->6.
I agree that python versioning and especially library packaging is the worst part of the language, though.
Agreed! My father (RIP) absolutely loved Perl and could do amazing things with it in seemingly impossibly-few characters. I got reasonably proficient w/ regex but never came close to his wizardry. Much respect for those in his rarified company.
There was no such pressure. That's ridiculous. There were a lot of things people could grab as reasons to form an opinion without even reading articles, never mind the tutorial. They then ended up with php or python, even java for crying out loud, and years later THAT was a problem.
There wasn't pressure to write concise code exactly, but if you posted your code somewhere the odds were good that somebody would reply with a way to do the same thing with less code, followed by someone else who managed to shave several lines/characters off of that, etc.
While almost all of the time it was all just people having fun (perl is fun and play was encouraged) and not an admonishment of the code you'd posted or an example of how it should have been written I can see how some folks might have gotten that impression. Especially if they were new to perl and were more used to languages where TIMTOWTDI wasn't thing
> There was no such pressure. That's ridiculous.
I lived it. I'm sure there's still some Mailing List archives and IRC snippets that still endure, demonstrating the utter vicious 1-upmanship of how to do something in Perl as succinctly as possible. Why do X and Y when you can just do Z? What are you really trying to do? etc.
You COULD, if you wanted, and spent quite a bit of effort in the pursuit of that hobby, participate in one-liner, or obfuscation, or golfing friendly contests. Which were enabled by perl's expressiveness constructs. Nobody pushed anyone into that. On the contrary "there is more than one way to do it" was there to legitimize that getting the problem solved was the goal - instead of trying to force a one true way (like python).
After that, experts would often propose multiple ways to do something when they answered questions. THEY found that intellectually playful and exciting. They still do. And for the rest of us, that was an amazing way to learn more and understand more of that tool we were using daily. Still is.
You apparently saw viciousness in this and that certainly sucks.
Those experts were horrendously vicious. I can name them and can still describe their dismissive cruelty, since I spent ten years socializing nonstop in the Perl5 core communities (and have a CPAN id, and have an Authors entry in Perl5 core). Think “Linus before he learned to stop insulting people’s worth and focus on critiquing their work instead”. It was absolutely intended as a form of cultural propagation: I can do this more succinctly, so You Should Be Ashamed Before Me. If somehow you weren’t exposed to that aspect of it, I envy you.
Interestingly, that same prideful “my way is so obviously better that it’s a ridiculous waste of my time considering yours” ended up carrying forward to Mozilla, which was launched in part by cultural exports of the Perl5 conservative-libertarian community, and for a decade developer hiring was filtered for cultural sameness, leaving a forest of TMTOWTDI trees that viewed meadows as an aberration to be reforested back to their sameness.
For me it wasn't cultural.
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.
I had an interesting experience starting a job at ZipRecruiter, and finding that up to that point (2022), most of their code had been written in Perl. Their CTO had just gotten fed up with Perl and decreed that from now on, all new projects should be written in Go. I was the first one on my team to write code in Go.
There were various greybeards who kept telling me that Perl was a perfectly fine language and was fast enough for most purposes. I didn't argue with them and just backed away slowly.
Regarding Perl as a language, it seemed fine in the 1990s as a slightly more advanced alternative to Unix shells. But for me, what made it a failure as a language is that in order to have an array of hashes, or a hash of arrays, you needed to use references. That may have been a nice hack to enable some things in the 1990s, but even in 2005 that sounds pretty primitive and outdated to me. Plus the reliance on using magical variables consisting of $ and every non-letter ASCII character for all kinds of random stuff, like $_ and $# and so on. That may have been cool in 1992, but it's not 1992 any more.
Overall, Perl was pretty neat for little scripts up to 20 lines, but a bad idea for building an entire company on (like ZipRecruiter.) That's more of an indictment of ZipRecruiter than Perl.
> [TIMTOWTDI] literally means 'there is more than one way to do it in Perl' - and you can perhaps infer from that that there's little to no reason to do it using anything else
Not my experience at all, FWIW. For me, and the vast majority of Perl devs I’ve worked with over the past 30 years, TIMTOWTDI absolutely means some of the “ways to do it” don’t involve Perl, and that’s not only OK but expected. Of course Perl isn’t the be all/end all. It’s a lot of fun though!
(I’m a majority Perl coder to this day, it’s my favourite language by far. Hell, I even find it readable and easy/fun to debug)
I think a big part is does someone starting to program even hear that Perl exists? No, and they start learning python and so have little need to learn Perl after that
Which is (sadly) hilarious because that was the reason most people seem to have gone with python: they were told "this is what we use here" or they bought the "line noise" nonsense. They never put much effort into this.
But I also think that people who are truly interested in programming immediately learn that there are many different paradigms. And the net makes it dead easy for them to explore different directions and, I don't know, fall in love with haskell or something. Perl is plenty visible enough for THAT. I don't know about perl 6 / raku though.
That's why it has stayed dead. But that can't explain how it died. People don't just spontaneously stop hearing about the existence of a programming language in common use.
early pearl was just about having an awesome tool at your disposal. There was minimal code written in a team environment.
People were still amazed that you could do X in 1 line rather than 100 lines. Some people couldn't have done those 100 lines.
So the idea of recipes/spells/hacks was an intentional parallel.
It became a cultural thing. New people wanted to be respected for compact code that impressed people the same way they were impressed.
My client uses IBM servers with it’s hobbled version of Unix (AIX). Perl and access to copilot have really helped me out. I don’t love Perl but I’m damn glad I have acres to it.
Rather than its "decline was", Perl's existence is cultural. All programming languages (or any thought tools) are reflections and projections of the cognitive values of the community who creates and maintains them. In short, the Perl language shares the structure of the typical Perl dev's mind.
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
The lede says Perl died because it was "reactionary" and "culturally conservative", but the content says Perl died because it had bad culture, the culture of angry, socially corrosive anonymous internet commenters.
If Perl had had a good culture, then conserving it would have been good!
A good culture, as time goes, is not reactionary and conservative, if only because it opens itself to the contribution of the younger generations.
The reason I mostly use Python is `python3 -mvenv env`. If I know that everything I might want is part of Perl's built-in modules, I prefer Perl.
Perl died for many reasons. For me, it was a language that was always too tempting to be too clever by half. I'd been using Perl pretty significantly from 1995-2000 (perl4 to perl5) when I was introduced to Python (1.5.2)[^1]. I greatly appreciated its simplicity, zen, batteries included standard lib, and REPL. I found add on packages easier to install than dealing with CPAN. I switched to Python and basically never looked back.
[^1]: https://news.ycombinator.com/item?id=44790671
I don't understand how Perl fell off and PHP didn't
Perl is a very difficult language. PHP was a comparatively simple language. PHP was just a scripting language for C and incorporated as many open source C libraries as possible back when open source libraries were a bit of disjointed mess.
PHP's success and Perl's decline was obvious at the time.
I think PHP is way more accessible syntactically, even with all the standard complaints about the language. In the early 2000s it felt like "simple C style function calls embedded in HTML templates" more or less. Not much to have to teach there.
And serving it tends to be "copy the files to your web server's public dir".
PHP is, at least for me, way, way more readable. Similar enough to Java that you don't have to re-learn syntax too much.
There is no doubt that a product’s community culture and the maintainer’s attitude have a significant influence.
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
Perl is still required for compiling autotools, openssl, nasm, etc.
As such, is likely to be around for a long, long time
Python is sometimes required for compiling software, too, but projects like the ones mentioned above requiring Perl have not switched to Python
I thought its decline was due to Perl's confusing syntax. That's what caused me to move away from it anyway.
Perl 5's non-breaking conservatism kept old scripts running forever, but it also meant there was never a clear migration path the way Python 3 eventually provided, and that made long term planning a lot harder.
Perl did have `use strict`, so there was at least some plausible path to making non-breaking changes under a new pragma.
The OP’s theory that Perl 6’s radicalism allowed Perl 5 to be conservative sounds right to me.
Though at the same time the bit where `use strict` was optional wound up being off-putting to a lot of us, at least in part because we'd always wind up with _something_ that wasn't designed for `use strict` and had, uh, interesting failure modes.
It's the same drive that we see from JS to TS these days, or adding type hints to Python, and even to some extent why people pick up Rust: because you get a refusal to act and an explanation rather than wonky results when you goof.
IME there's been a wider shift away from worse-is-better, and Perl was kind of one of the early casualties of that. Part of that is also how science has marched on: When Python and Perl were new, the most popular typed languages were kind of tedious but not what people would consider _good_ at types these days. Perl was the first language I learned, and if I was transported back to the 1990s, I'd probably still pick it, even if I don't use it in 2025.
(OK, maybe I'd go all in on OCaml. Any way the camel wins.)
I never really warmed to perl in its era but perl dbi was kind of perfect in its way. If you needed what it could do, it got very intuitive very fast, and was pretty terse. Both of which were supposedly the appeal of perl.
I didn't like cpan and python was just easier and available, if python didn't exist I'd like to think I'd have invested heavily in perl because it was everywhere at some point.
The number of blogs posted on here by people who can’t be arsed to make their writing legible on mobile blows my mind. Did everybody just skip the section of their CSS journey that covered media queries or what?
I enjoyed the article but it was a nightmare to read on my phone’s browser
Perl6/Raku killed Perl.
Python 3 almost killed Python.
It's normal. Once a community loses faith, it's hard to stop them from leaving.
I'd take this a step further and say that the design flaws that motivated Perl6 were what really killed Perl. Perl6 just accelerated the timeline.
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.
Agree 100%. We were told to wait for any improvements or new features we wanted and just to wait for Perl 6, which never came
Yep. Perl 6 was a wall that Perl 5 would never move beyond. It’s still Perl 5 25 years later.
Python 3 couldn't even kill Python 2!
> Python 3 almost killed Python.
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.
Python 3 was a disaster and enterprises were still undertaking pointless 2->3 upgrade projects 10 years later
A month ago I had to fix a small bug in Python 2.6 code in one of internal systems. It won't be ever migrated, no capacity and no value
It was not a disaster in any way. People just complained about having to do something to upgrade their codebases.
It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode.
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.
> It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode.
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 can't say i've ever thought "wow I wish I had to use go's unicode approach". The bytes/str split is the cleanest approach of any runtime I've seen.
With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade.
Imagine if the same interpreter supported both Python 3 and Python 2. Python 3 code could import a Python 2 module, or vice versa. Codebases could migrate somewhat more incrementally. Python 2 code's idea of a "string" would be bytes, and python 3's idea of a "string" would be unicode, but both can speak the other's language, they just have different names for things, so you can migrate.
> With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade.
Not without enormous and unnecessary pain.
It would absolutely have been harder. But the pain of going that path might potentially have been less than the pain of the Python 2 to Python 3 transition. Or, possibly, it wouldn't have been; I'm not claiming the tradeoff is obvious even in hindsight here.
The real problem here was releasing 3.0 as if it was stable, when the real usable version was 3.3/3.4
perl died because "Perl is write once, read never"
> Perl always had a significant amount of what you might call "BOFH" culture, which came from its old UNIX sysadmin roots. All of those passive aggressive idioms and in jokes like "RTFM", "lusers", "wizards", "asking for help the wrong way" etc.
> [...]
> Cultural conservatism as a first principle.
Counterpoint to this: Rust. Rust has a similar RTFM/"wizards" culture, but is not culturally conservative (in any sense of the word).
My two cents: Perl's "culture" had little to do with its fall. I think Perl's problems run much deeper. Perl is built on rotten foundations. It's fundamentally a scripting language (albeit with bolted on additions to make it kinda-OOP), and it therefore has all the problems that scripting languages have for building large software projects.
Those problems have no quick fix, and indeed fixing them would require throwing the language out entirely -- at which point, why not simply switch to another language entirely (which is exactly what happened...).
Probably stretching the cultural metaphor too far here, but Rust has much more of a “vanguard of the proletariat” vibe & appears susceptible to some of the problems inherent in that political mission.
Python is mentioned and I think the key reason it's continued to grow while Perl declined, is a vastly more welcoming culture.
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.
"Willing" is an interesting word choice. There was quite a bit of resistance in the Python world despite the clear benefits. (2.x really could not be fixed, because the semantics were fundamentally broken in many places.)
It's open source.
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.
> Any one ( and I'm sure a few have tried) can fork 2.x and keep using it.
They have tried and succeeded: https://docs.activestate.com/activepython/2.7/
I still consider the result "broken".
I looked at Perl once and decided to just not use it, and hoped it'd go away so I never have to use it. Sorry, the decline was probably due to it being bad.
Perl being so old means it's extremely fast for what it's designed to do, process streams or pipes. In a few tasks, it's faster than C, but being much faster to create a script or program that is useful, and with the implicit syntactic sugar, and since it's so flexible, you can just do things in the one way you know how and that's usually good enough.
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.
Perl is amazing when it comes to regular expressions too. It's one of the reasons why perl is way more fun to write than Python. I still use perl for regex heavy tasks. I wish that python had integrated regex into the language the same way.
I worked for a few years in an large org which utilized perl for build scripts, testing automation, and a few other things. I would summarize the half decade Perl learning curve as initial bewilderment, intermediate cult like praise, to advance level disillusionment.
There was something about scaling usage in large teams that felt awkward and high friction.
I spent year developing CMS in Perl in 1999 (HTA application with ActivePerl. wonder if anybody else did something like this). It traumatized me, and first thing that I did in my next job is to learn python and develop some core systems in it. Few of my friends moved from perl to python as well.
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
Before I eventually switched to PHP, I ended up writing multiple CMS-like solutions that would run via `cgi-bin` but write contents to the webroot (what we would now call a static site generator). As I was quite limited with the standard shared hosting at the time, I ended up inventing my own single file database format (it was a simple text file) to keep state. It worked quite beautifully and kept me afloat for the first few years of my life as a web developer around the early 2000s.
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.
I wrote php2 + msql before starting in that company (and a bit of php3). Like in your case it was essentially static site generator but the management part was HTA (application hosted in internet explorer. you could write one using whatever activex/language: vbscript, python, perl).
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)
Perl heads are downvoting you but I agree as a longtime ex Perl user that the sigils were noisy nonsense.
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.
and people wonder why raku had so many things it needed to change to free the excellent core of the language and its ideas
Oops last example should be $hash1->{“hash2”} - this is a whole hash referenced with $ because of the implementation detail that it is in hash1 as a reference, which is considered a scalar.
Technically you are allowed to use % like so: %{$hash1->{“hash2”}}. Which, just - lol.
Before that job in perl i wrote asm/tcl/delphi/c/php (and bunch of other languages after).
This perl syntax caused some kind of rejection on almost physical level. It was same for many of my friends. "Zen of python" was a breath of fresh air.
Perl was of a time, so it's important to remember when it was around. CPAN was legitimately one of the first package managers for a programming language that WORKED. Contextually, its references are bash, sed, awk, and other cli tools. There are too many ways to do things in perl because of the various flavors / takes on how to do things. It was also a fun way to write cgi apps in the era of C/C++. Is that the best way to do things today? No! It was one way to do something complex in few lines of code. It was the python of its day in many ways.
There are tons of quirks that are interesting that influenced language development today, for me the spaceship operator "<=>" was a fun one. You can have a flip through the camel book to see what kind of stunts were common in its era.
It is an auteur language that was not really done the way languages are today.
Perl 6 did massive damage to the community mainly because it was so different that it looked like a fantasy language. That along with Parrot really lost the plot for me, I had mostly stopped doing that kind of work and moved on to R for my bioinformatics things. Bioconductor was the bees knees.
I'm surprised at all the haterade, probably you're either <30, and/or being overly critical of a very nascent tech era. Perl was pre and post .bomb, and had one of the first online communities that I remember that shared tips and tricks at scale at perlmonks.org. It predated stackoverflow! It was a very different time to now.
This was also from a time when people still paid for compilers(!)
I am deeply biased, as I wrote a 3d distance calculator in Perl for small molecule drugs. We were looking for disulfiram analogs doing biopanning and then simulations. There was a great PDB library for structures at that time that saved me tons of time. This was circa 2005~, ages from now.
Related:
What Killed Perl?
https://news.ycombinator.com/item?id=45977900
Nah Perl just wasn't a very good language. Not every language is equally good.
Careful, we are not allowed to say such things.
Ironically alluding to the possibility of others who would castigate you for saying something reasonable things, is not any less obnoxious than the castigation.
We don't have to say such things, because the syntactic sirup of ipecac and sputtering line noise of perl code speaks for itself.
Clearly not loudly enough - look at all the people here searching for some mysterious cultural reason it failed.
C'mon. The language was like something born in Hogwart's. Magic spells, incantations. It lost because it was not an easy language to learn - and others were (in particular Python) - while being just as powerful.
I don't get why Ruby is mentioned before PHP. The only Ruby thing I've ever come across is GitLab, and not with positive associations either - up until maybe 3, 4 years ago particularly Sidekiq was a constant point of utter pain.
I was surprised by that, too, and assumed it was a decade-old article until I saw the date at the bottom. Both being mentioned before Python is wilder, as is the total exclusion of JavaScript.
JavaScript on the backend is a rare thing to see, even in "resume driven development" scenarios it's usually some sort of static build that gets pushed to S3 or whatever.
Are you time traveling from 1998, when AOL acquired Netscape and sidelined Livewire?
Node.js is the most popular web framework/technology in the StackOverflow developer survey. Express is more popular than FastAPI, Django, Flask and Rails in the same survey. Just... what are you talking about?
i disagree, python is Just Better. ive never used perl but ive had to install it due to some antique tools requiring it, and every time its been an incomprehensible mess. i still have no idea how packages work in perl. also, it seems like everything in perl is a string? and the syntax looks like a mess.
maybe its painful for guys to admit that languages could be a lot better designed, and when such langauges appeared, everyone flocked to them.
> also, it seems like everything in perl is a string?
It's actually somehow even worse than this. The Perl type system is honestly ridiculous. Most veteran Perl developers don't fully understand it.
https://blogs.perl.org/users/leon_timmermans/2025/02/a-deep-... is a good introduction.
Perl's "decline" saved it from a fate worst than death: popularity and splitting into dozens of incompatible versions from added/removed features (like python). Instead Perl is just available everywhere in the same stable form. Scripts always can just use the system perl interpreter. And most of the time a script written in $currentyear can run just as well on a perl system interpreter from 2 decades ago (and vice versa). It is the perfect language for system adminstration and personal use. Even if it isn't for machine learning and those kinds of bleeding edge things that need constant major changes. There are trade-offs.
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.
Perl's binary brings with it the ability to run every release of the language, from 5.8 onwards. You can mix and match Perl 5.30 code with 5.8 code with 5.20 code, whatever, just say "use v5.20.0;" at the start of each module or script.
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.
> By comparison, Python can barely go one version without both introducing new things and removing old things from the language
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.The Python approach seems better for avoiding subtle bugs. TIMTOWTDI vs "there should be one obvious way to do it" again.
What incompatible versions of pythons do you mean? I'm entirely unaware of any forks, and the youngest version I have to supply at the moment is 3.9, which is over 5 years old and available in all supported platforms.
Try to run any random python program of moderate dep use on your python 3.9 system interpreter without using containers. Most likely you'll have to use a venv or the like and setup a special version of python just for that application. It's the standard now because system Python can't do it. In practice, pragmatically, there is no Python. Only pythons. And that's not even getting in to the major breakages in point version upgrades or the whole python 2 to 3 language switch.
> Most likely you'll have to use a venv or the like and setup a special version of python just for that application.
Using venvs is trivial (and orders of magnitude more lightweight than a container). And virtually every popular package has a policy of supporting at least all currently supported Python versions with each new release.
You need to set up a venv because of how the language is designed, and how it has always worked since the beginning. Python doesn't accommodate multiple versions of a package in the same runtime environment, full stop. The syntax doesn't provide for version numbers on imports. Imports are cached by symbolic name and everyone is explicitly expected to rely on this for program correctness (i.e., your library can have global state and the client will get a singleton module object). People just didn't notice/care because the entire "ecosystem" concept didn't exist yet.
I have at least one local from-source build of every Python from 3.3-3.14 inclusive (plus 2.7); it's easy to do. But I have them explicitly for testing, not because using someone else's project forces me to. The ecosystem is just not like that unless perhaps you are specifically using some sort of PyTorch/CUDA/Tensorflow related stack.
> It's the standard now because system Python can't do it.
Your system Python absolutely can have packages installed into it. The restrictions are because your Linux distro wants to be able to manage the system environment. The system package manager shouldn't have to grok files that it didn't put there, and system tools shouldn't have to risk picking up a dependency you put there. Please read https://peps.python.org/pep-0668/, especially the motivation and rationale sections.
> major breakages in point version upgrades
I can think of exactly one (`async` becoming a keyword, breaking Tensorflow that was using it as a parameter name). And they responded to that by introducing the concept of soft keywords. Beyond that, it's just not a thing for your code to become syntactically invalid or to change in semantics because of a 3.x point version change. It's just the standard library that has changes or removals. You can trivially fix this by vendoring the old code.
My language learning trajectory (from 10 years old) was 8086 assembly, QBASIC, C, Perl, Java, MAGMA, JavaScript/HTML/CSS, Python, Haskell, C++, vibe coding
How old are you now? Mid fifties here. And 'vibe coding' in what exactly - it is not of interest from a programming perspective, but from a 'what does the AI know best perspective'? I've followed a similar, but not identical trajectory and now vibe in python/htmx/flask without needing to review the code in depth (NB internal apps, not public facing ones), with claude code max. Vibe coding in the last 6-8 weeks now also seems to make a decent fist of embedded coding - esp32/arduino/esp-32, also claude code.