I wrote a lot of Perl 3 and Perl 4 to date my experience.
Rails was designed to be a luxury hand-holding experience using a language that was intended - as a design goal - to make programming fun. There was even for a while in the late 2000s the culture of _why and MINSWAN.
PHP was fast, easy, forgiving. It also led to such awful code that several companies banned it. I think nearly all of us who got to deploy code with nothing more than FTP miss that. Of course today it runs more of the web than any other language.
Perl on the other hand wasn't interested in any of that, so many people just left because they were pulled by better ecosystems that took the web seriously, or pushed by a culture that believed the priesthood was real.
For me, Rails and Ruby were genuinely joyful discoveries after spending a couple of years wrestling J2EE and .NET apps in the ~2002-2005 era, and the Perl community felt crusty and unwelcome and immature by comparison.
Today I'm no fan of come of the politics of people being some popular Ruby frameworks cough, but I enjoy Ruby and I'm enjoying my dive back into systems programming via re-learning C and taking a long look at Zig. I'm not sure I'll ever write "production" Perl again.
It was a great time - titles like Learn You A Haskell For Great Good and Land of Lisp really capture the zeitgeist.
Or did the language itself just get outdated and replaced? (there's nothing wrong with that! most things don't last forever!)
Any company/organization can theoretically change its culture, but it's quite difficult in practice.
That's not the case nowadays with PHP 8.5 for example... and Laravel framework.
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”.
Or doing a plain set of scripts into a repo, instead of endless arguments how fit a module implemenents the onion and hexagonal architectures, clean code, or whatever is the trend in this year's architecture conferences.
Also… a lot of that complexity is essentially self-inflicted.
I must say however: “devops” is completely different from what old-school system administration used to be.
This, it was very unixy and felt like a natural progression from shell scripting. I think that's why a lot of early linux adopters were so enamored.
On the other hand, I was able to easily pick up just about any "tradional" language I tried--from Basic and C in the 80s all the way to Dart and Go more recently.
YODA: No... no... no. Quicker, easier, more seductive.
LUKE: But how will I know why Python is better than Perl?
YODA: You will know. When your code you try to read six months from now.
It lets you write shell scripts with clojure. Babashka itself is a single executable, so no JVM bulk or startup time. And the built-in libs include all sorts of nifty utilities. Parsers, servers, excellent async stuff (but IMO clojure might have the best async story of any language out there so I’m biased), http stuff. All macro-able and REPL-able and everything. It’s a scripting dream, and when it’s time to be an adult, you can throw it on the JVM too!
Also the culture wasn’t hostile to me as a newcomer. The Perl books I read encouraged not writing overly terse, cryptic code, and I got helpful answers via mailing lists.
I still use Perl sometimes if my command pipeline gets too complicated.
> 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!"
It certainly was the major factor in how I connected the dots!
Haven’t really thought about it until now, but I suppose having Larry Wall and Randal Schwartz telling you to RTFM guides your early development in a certain manner.
I certainly have never considered myself a developer or programmer though. I can pick up enough syntax to get a quick hack done or start a MVP to demo my ideas, but I leave the “big boy” dev stuff to the professionals who can run circles around me.
I'm sure there are people who started in a language and later found something that made more sense. I'm just reflecting on what I've found in my experience.
That's so funny to me; I like Python, and dislike Perl & Ruby. Something about Ruby rubs me the wrong way - I could name a few things that I think are _objectively_ bad decisions in the language's design, but it's mostly about an aesthetic preference that's just a matter of taste.
When at University the academic running the programming language course was adamant the Sapir–Whorf hypothesis applied to programming language. ie language influences the way you think.
> "A lot of the mystique of APL is because it's illegible ... nothing more than a DSL for 'numpy-like' code. .. same demo, using Julia and the result is (in my opinion) much more legible: ... let n=sum(map(
sum() in Julia is more clear and more readable at a glance than +/ in APL, but the APL version is a combination of two things. + which is a binary addition function, and / which is reduce, a higher-order operator or meta-function. sum() in Julia doesn't lead you to think about anything else except what other builtins exist. The APL notation leads you to wonder about combining other commands in that pattern, like times-reduce is ×/ and calculates the product of an array of numbers. From the notation you can see that sum and product are structurally related operations, which you can't see from names sum() and product(). Then you change the other part by wondering what plus does if used with other higher functions, like +\ (scan) and it's a running-sum across an array. (i.e. "+\ 1 1 1 1" gives "1 2 3 4", the sum so far at each point).
So the notation isn't just about readability, it's a tool for thinking about the operations. Different notations enable you to think about different things. If we imagine there was no sum() then you might write:
sum = 0
foreach (n in numbers) { sum += n }
product = 0
foreach (n in numbers) { product *= n }
> "the power of abstraction of APL is available to any other language, with the right functions. ... there's nothing to stop anyone from aliasing array-functions to their APL equivalents in any Unicode-aware language, like Julia (oddly, nobody does)."
Maybe nobody does it because if you can't take the patterns apart and put them back together differently without an APL engine behind it, is there any benefit? Take an example from APLCart[2]:
{⍵/⍨∨\⍵≠' '} Dv # Remove leading blanks [from a character vector]
{⍵≠' '} ' abc def' # make a boolean array mask
┌→──────────────────────┐ # 0 for spaces, 1 for nonspaces
│0 0 0 1 1 1 0 0 0 1 1 1│
└~──────────────────────┘
{∨\⍵≠' '} ' abc def' # logical OR scan
┌→──────────────────────┐ # once a 1 starts,
│0 0 0 1 1 1 1 1 1 1 1 1│ # carry it on to end of string
└~──────────────────────┘
{⍵/⍨∨\⍵≠' '} ' abc def'
┌→────────┐ # 'compress' using the boolean
│abc def│ # array as a mask to select what to keep
└─────────┘
{⍵/⍨∨\⍵≠0} Dv # Remove leading zeroes [from a numeric vector]
Which part of that would you alias in Julia? I suspect you just wouldn't write a trimstart in this style in Julia like you wouldn't in C#. You wouldn't think of using an intermediate boolean array.
It's not just about "readability", the APL notation being concise and self-similar reveals some computy/mathematical patterns in data transforms which "giving everything a unique English name" obscure. And APL notation hides other patterns which other notations reveal. i.e. Different notations are being tools for thinking differently about problems, Notation as a Tool for Thought.
+ - * / and other operators work not only on numbers but on strings, arrays and other types and all have an intuitive application.
on strings and arrays for example, + is concatenate, / is split, * is join, - is filter (with static values).
I wish bash was the thing that was dying. As an industry, we need to make better choices.
I write bash scripts only because I can rely on it being there.
Chet Ramey became the primary maintainer of Bash in the early 1990s and is the sole author of every bash update (and Readline) since then. That would be an enormous task for a team of 100, no less a team of one.
I've become quite a fan (after struggling mightily with its seemingly millions of quirks.
(And yes, I have been pushing for bash or posix sh).
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.
Perl 5 is to me a classic scripting language (as opposed to an actual programming language), for both good and bad. I've always viewed Perl scripts with exactly that perspective and I find them fine/good. In contrast, I find Python to be a mediocre scripting language, an okay-ish programming language from a syntax perspective and a bottom-5 programming language in pretty much every other regard.
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.
- 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?
$_ 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.
Yes, that's exactly the problem: it's additional mental load you have to read up on.
Have 60 of those small oddities in a file, and suddenly you're spending an hour dealing with Perl quirks rather than actually debugging that obscure script a retired coworker wrote a decade ago. A 5-minute fix turned into a 65-minute fix, solely because of Perl.
Most programming languages use more-or-less the same constructs, and the few per-language oddities are usually fairly obvious from context. In practice this means someone familiar with any programming language will to a certain extent be able to read, debug, and patch small issues in code written in any other programming language. Perl's obscure and dense syntax makes this virtually impossible. Give a buggy Python script to a developer who daily-drives Javascript and they can probably fix it. Give a buggy Perl script to that same Javascript developer, and they probably have absolutely no clue what's going on.
In practice this turns Perl into technical debt. It has very few natural niches where it is genuinely the best, so experienced Perl developers are quite rare to have around. Any script written in Perl will most likely have to be read by someone who isn't an experienced Perl developer - which is significantly harder than a script written in just about any other language. The result is that any Perl scripts you have lying around are basically a grenade waiting to go off: they can't be maintained, so they should probably be replaced.
OK, I had never heard of the syntax, but in its own defense it does exactly what you'd guess, the same thing it does after an "if".
These are equivalent statements:
preloop:
if condition:
do_more_stuff()
goto preloop
while condition:
do_more_stuff()
preloop:
if condition:
do_more_stuff()
goto preloop
else:
wrap_it_ip()
while condition:
do_more_stuff()
else:
wrap_it_up()But here, from the official documentation:
> if the expression is false (which may be the first time it is tested) the suite of the else clause, if present, is executed and the loop terminates.
https://docs.python.org/3/reference/compound_stmts.html#the-...
The only reason AWK needs a BEGIN is due to it's implied data loop. As far as I know perl has an explicit data loop and as such needs no BEGIN.
Oh god, perl has an implied data loop mode doesn't it. Sigh, now I am reading perl manpages to find out.
Update: of course it does, -n or -p
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.
This is an amazing point that I haven't seen anyone else make about languages in this way.
As someone who got into the industry right after Perl's heyday and never learned or used it but learned programming from some former Perl power users, Perl has a pre-corporate/anarchic/punk feel about it that is completely opposite to something like Golang that feels like it was developed by a corporation, for a corporation. Perl is wacky, but it feels alive (the language itself, if not the community). By contrast, Golang feels dead, soulless.
The Pragmatic Programmers had just started praising Ruby, so I opted for the that over Perl, and just went with it ever since. Hated PHP and didn't like Python's whitespace thing. I never Ruby on Rails'd either. That said my first interactive website was effectively a hello world button with cgi/perl.
But trying to learn to code from reading other peoples perl scripts was way harder than the (then) newer language alternatives.
Now I'm over 50 none of that is nearly as important. I remember being young and strongly opininated, this vs. that - its just part of the journey, and the culture. It also explains the current FizzBuzz in CSS minimisation post. We do because we can, not necessarily because we should.
Perl and some of Perl's quirks will make more sense once you realise that it is deeply rooted in UNIX command line utilities, UNIX conventions and some UNIX shell defaults, except when it is not, i.e.
- What is `$_`?
- What is this BEGIN block at the start of this Perl file? Why is that necessary?
- What does chomp do when it's just on its own line, with no arguments given to it?
Hopefully I am paraphrasing you correctly.
The one thing I could never ever get was using a regex - not the regex itself but the line to actually use it.
Python was so much easier as it was simple define the regex and then use a function on it. I suppose I should hjave spent a few days to write some wrapper in perl - doing those few days would have saved me time overall.
As for one liners I was originally an APL programmer so not a problem. But it is just bad style to write a one liner much better to write it in a maintainable form and split up the operations so they can be seen.
Nowadays I ddon't use lambdas if possible - much better to have a named function you can refer to.
That's funny. I avoid python whenever possible, but one of the things I hate the most is how it is doing regex. I find the way it works in perl (both for search/replace and in conditionals) just intuitive.
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.
Those days were different. You could say what people are doing in months to years today, in many ways people back then were doing in days to weeks.
Pace and ambition of shipping has not only faded, that very culture is non existent. You don't see people building the next Facebook or Amazon these days, do you?
I remember managers asking Java programmers how much time it would take to get something done, and get timelines on months and years. They would come to us Perl programmers and get it done in a week.
The era didn't last long. I would joke around our team saying, ideally a Java programmer with 10 years experience was somewhat like like a Perl programmer with 1 year experience. This was one of the big reasons, most of these enterprise coders wanted Perl gone.
Do you not? The pace of anthropic/Claude tool development is pretty bonkers, AI hype reminds me of the 90s a lot.
I see some people disagree with you, but reading this reminds me of this anecdote :
My brother has a very high IQ score, but poor social skills. He once found employment in one of the very early companies developing websites in our area.
There was a process requiring to manually check hundreds of links for validity, which took large amounts of time to do (as in several developper hours weekly), and was error prone at that. The details are fuzzy as this happened some 30 years ago or so, but essentially he found a logical way to do the thing without error in 15 minutes.
The other developers went on a rampage to dismiss the solution, for fear of looking like idiots, and even though the solution was provable, my bro go fired, and went on to become a mechanic. What a shame though.
So, your comment rang a bell.
Also : I make a living developing and maintaining a handful of custom made SaaS for small clients on a LAMP stack (Linux Apache Mod_perl Postgresql). Very thrifty.
Little money, but loads of fun as far as I'm concerned
The Perl community introduced the world to the first language module repositories via CPAN. No more manually hunting down tarballs off FTP servers
As a language, Perl is extremely expressive, which is amazing for one-off scripts, and awful for code that's meant to be shared and/or reread. For pure text-munging, Perl is still unbeaten, when using Perl-Compatible regexes in other languages, I feel the language getting in my way.
You can write easy-to-read Perl (TIMTOWTDI, and all that), but it doesn't force you like Go (small language size) or Python (by convention and culture, on what counts as 'Pythonic')
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.
There’s a whole lot of words popularly excised (as you just did) from that line of the Zen to create a false polar opposite to Perl’s TMTOWTDI that was never actually part of Python’s philosophy.
The actual line from the Zen of Python is: “There should be one—and preferably only one—obvious way to do it.” (omissions in italics).
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
But those who remember the regulars of, say, efnet #perl (THIS ISN'T A HELP CHANNEL), there was a dearth of kindness for sure. I was probably part of it too, because that was the culture! This is where the wizards live, why are you here asking us questions?
Like cms, I'm also hesitant to name names, but the folks I'm thinking of were definitely perl-famous in their day.
There were also a bunch of great people in the community, and they helped me launch my career in tech in the 90s, and I have close internet friends from that community to this day (and great memories of some who have passed on). But there were definitely also jerks.
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.
Not really. Bash is known to be incoherent (due to legacy). You eventually getting accustomed to its quirks but they still remain absurd and may unexpectedly bite you someday. Perl code can, and perhaps will (it's humorously referred to as a write-only language afterall), get hard to read but at least is more robust.
Python forums in contrast to me included neverending justifications for why whitespace and indent formatting was critical and this kind of odd (to me) imperfect type system implementation, like the whole thing was some toy language pretending to be more than it was (in the sense that if you wanted something more complete in language or performance you'd go elsewhere).
Perl just seemed to know its place and not take itself too seriously.
Things changed though. I haven't touched Perl in years but use Python all the time. I never understood why Python got the traction it did given its performance limitations compared to some other languages (except as part of a broader trend for people to use whatever language they leaned in introductory comp sci) but I do think I understand why people stopped learning Perl.
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.
That made me laugh. Unlike actually working with Perl references, which made me want to cry.
Just yesterday, I moved some 100 lines of code using a hash quite a few times from the main module to a function using a reference to the hash.
if %args is the hash holding the data, '$args{key}' tells me the value of 'key' in the main module.
a reference to the hash passed to the function is noted like so : '$args = \%args';$args->{key} tells me value of 'key'
All I had to do to adapt the code was to replace '$args{' with '$args->{', done by the time I typed the replace command in my editor.
Funny that it just makes sense to me, must be something with the brain's wiring.
67 stands for «whatever», «I don't care», or, cyclically, 67!
41 is an expression of shock or disbelief – «that's wild», «no way» and stuff like that.
That’s a very big number!
Pretending to be a all serius grown ups language is cringe.
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.
Rubyists vs. Pythonistas isn't any better.
Programming languages as counter-cultural lifestyle choices is pretty "cringe" as the kids say.
Humans are tribal, and HR only hires for specific bullet points, thus everyone wants to assert they are on the right tribe when they need to go job hunting.
Also, the early 2010s are not that recent: https://books.google.com/ngrams/graph?content=Pythonista%2Cp...
Eh, in different ways. Ruby people often felt a little smug/over-emotive about how much joy using their tool could bring programmers. TFA is spot on about Perl: Perl folks often felt cliquish, arrogant, defensive. Python people are at times patronizing or overly dismissive.
And in all of those communities the biggest difference was how many people in the community had those dysfunctions, versus the rest—the vast majority of each language’s users who were using it, sharing techniques or code, answering questions about it without being jerks.
Where Perl fell down for me was that its community and people I knew who used it had a much higher chance of evidencing those crappy behaviors. More bad apples—not many in the grander scheme, but enough more to be noticed.
That and Perl giving me a reason to do safe programming in UNIX with a managed language that exposed all the UNIX API surface, and only switching back into C when I actually needed some additional perf, or low level stuff not fully exposed in Perl.
Then again, I am also a fanboi of Haskell, C++, Scala, Idris and similar "wizard" languages.
man 3pm Errno
my $fh;
unless (open($fh, "<", "/fangorn/spouse")) {
if ($!{ENOENT}) {
warn "Get a wife!\n";
} else {
warn "This path is barred: $!";
}
}
That is just how I felt about Perl (4 years full time dev in the 2000s) and how I now feel about https://raku.org (aka Perl6). Anyway, I tried to gather some fellow feelings here about 18 months ago:
https://rakujourney.wordpress.com/2024/05/22/perl-love-notes...
It is sad that Perl became so despised after the error of preannouncing a non-compatible upgrade. I understand that people couldn't wait. But Raku is here now and it is worth a second look imo.
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!
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.")
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)
Either way, it's not meant to be taken so literally!
Edit: But I see your point, Google SRE’s around the late 2000’s reached for Python more than Perl.
Sysadmin-driven companies (typically Sun-based) often used Perl.
Developer-driven companies used other languages running on cheaper X86 Linux.
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.
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!
The syntax, full of @ and %, was convoluted and made you have to think about more things compared to Ruby or Python without giving you that much apparent power or benefit (as opposed to when you'd need to think about types more in Java or a C-family language).
Neither Ruby, Python, nor Perl were in my first three languages (Pascal, C/C++, Java were those). Ruby, Python, Matlab, R, and Perl all came later for me, within a few years of each other. Perl did not have anything like the approachability of Ruby and Python coming from that Pascal/C/Java background.
(IMO Python is losing some of that now, especially like in the last project I encountered in a professional capacity in Python where optional type hinting was used but wasn't always accurate which was a special sort of hell.)
EDIT: the article even touches on this some in its description of Ruby: "Ruby is a language for programmers, and is at this point an sensible candidate for building something like Rails with - a relatively blank canvas for dynamic programming, with many of the same qualities as Perl, with less legacy cruft, and more modern niceties, like an integrated object system, exceptions, straightforward data structures." Ruby was newer, and wasn't something that grew out of sysadmin tools, but was always a full fledged OO application programming language first. So my disagreement with the article is that the culture then doesn't matter because no perl culture changes would've been able to reinvent the language as a nicer, newer language like Ruby because it never would've been perl anymore at that point.
But that's the entire purpose of optional type hinting. If the hints had to be accurate, you'd have mandatory typing, not optional hinting.
It's not checked, it's not required, and the bolted on syntax is ugly.
Even if the types were checked, they'd still fail at runtime and some code paths wouldn't get exercised.
We need a family of "near-scripting" languages like Go that check everything AOT, but that can be interpreted.
It is both of those if you use a typechecker, which is the whole reason it exists (in fact, the first popular typechecker existed before the annotation syntax using type comments; type annotations were developed specifically so that it could be accommodated in the language rather than becoming its own separate language.)
Having to rely on process for validity is a recipe for bad. We already know how the greater python community has been with requirements.txt and dependencies. I've spent days fixing this garbage.
It's a tooling problem. Good tools make good habits part of the automation and stop you from having to think about it.
You could have optional type hints where the runtime would still yell at you - maybe even from just an optional flag - if you returned a string out of a function that should return an int.
Because as-is, once you have those function that says it returns an int but returns a string instead, etc, in a big codebase, your editor tooling gets really confused and it's way worse to work through than if the hints weren't there at all.
(And there are tools in Python that you can use to inspect and verify the accuracy. But those tools are also... optional... And if you start to apply them to a codebase where they weren't used, it can be very time-consuming to fix everything...)
How is that "bad" solution different from this "good" one?
> You could have optional type hints where the runtime would still yell at you - maybe even from just an optional flag - if you returned a string out of a function that should return an int.
- you don't need to install additional packages
- you could have (because you don't want to hurt prod perf by checking all the time) dev-mode with warnings by default on execution and a prod-mode where they're ignored
- you can then have people in the dev environment catching things as they write/run/test their code vs only whenever they run the third party tool (which it seems a lot of people don't set up for even run-on-every-commit)
Let's flip the question around! What do you think are the benefits to making it easy to add misleading incorrect type hints?
Perl is not that good a language though for practical purposes. The same way, a breadboard contraption is not what you want to ship as your hardware product, but without it, and the mistakes made and addressed while tinkering with it, the sleek consumer-grade PCB won't be possible to design.
Perl lets every developer write Perl in their own idiosyncratic way.
And every developer does.
It makes for very un-fun times when I'm having to read a file that's been authored by ten developers over ten years, each of whom with varying opinions and skill levels.
I guess in 2026, it'll be 11 developers writing it over 11 years. My sincere apologies to those who come after me, and my sincere fuck-you to those who came before me. :)
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.
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.
Perhaps too, a tool that's been around and in active maintenance for 11 years has been wildly successful.
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.
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....
It has so many great pieces of advice that apply to any programming task, everything from naming variables, to testing, error handling, code organization, documentation, etc, etc. Ultimately, for timeless advice on programming as a profession the language is immaterial.
It is, however, a significant language. It has left a mark and influence on the culture and industry of programming. Nothing to sneeze at.
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.
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 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.
How do you figure?
The essence of FP is functions of the shape `data -> data` rather than `data -> void`, deemphasizing object-based identity, and treating functions as first-class tools for abstraction. There's enough dynamic FP languages at this point to establish that these traits are held in common with the static FP languages. Is Clojure not an FP language?
> 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.
All data in Elixir is immutable. Bindings can be rebound but the data the bindings point to remains immutable, identical to Erlang.
Elixir just rewrites `x = 1; x = x + 1` to `x1 = 1; x2 = x1 + 1`. The immutable value semantics remain, and anything that sees `x` in between expressions never has its `x` mutated.
> 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.
I did a large amount of Scala prior to doing Erlang/Elixir and while I had a lot of fun with Applicative and Monoid I'm not sure they're the essence of FP. Certainly an important piece of the puzzle but not the totality.
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.
my @var = @array # copy the array
my $var = @array # return the count of elements in array my($f) = `fortune`; # assigns first line of output to $f.
my $f = `fortune`; # assign all output to $f.
[^1]: "It's all about context" (2001): https://archive.ph/IB2kR (http://www.stonehenge.com/merlyn/UnixReview/col38.html)
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)
my @lines = `fortune`
foreach my $line (`fortune`) {}
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`
you gave it array, and it just did what it does with arrays.
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.*
Even C gets it's fair share of flack for how it overloads * to mean three different things! (multiplication, pointer declaration, and dereference)
array var = array # copied
int var = array # length
var = array # copied
var = array.to_i # length
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.
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.
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 (and not complaining about the line noise nonsense). 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 think this was one of those things people just repeated, rather than having concrete examples from experience. It's like people saying a Toyota Corolla is better than a Honda Civic. Is it really? Or are they really just two different forms of the same thing? They both get you to the grocery store, they're both very reliable, small cheap. Having a preference is not the same thing as one actually being superior to the other.
It was Django and the people involved with it.
Culture?
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.
So @_ was a response to that issue, given Perl was about being dynamic and not typed and there were no IDEs or linters that would type-check and refactor code based on function signatures.
JS had the same issue forever and finally implemented a rest/spread operator in ES6. Python had variadic from the start but no rest operator until Python3. Perl had spread/rest for vargs in the late 80s already. For familiarity, Perl chose the @ operator that meant vargs in bourne shell in the 70s.
(defun frobnicate (foo &key (bar (Vector 1 2 3)) (baz 'quux))
(declare (type Foo foo)
(type (Vector Integer) bar)
(type Symbol baz))
...)
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)
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.
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.
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.
Once languages came along that did okay regexes and good hash tables along with getting other stuff decent, Perl just got pushed aside.
I still find the occasional Perl script in my current job, usually going through someone's legacy infrastructure, and I always have the same reaction, "phew I'm glad I switched to Python".
That reaction has nothing to do with the culture, it's 100% technical.
Just a few of the main points, I don't know why Perl coders were so adverse to comments, it's almost like some of us took a perverse pleasure in producing the most illegible piece of code.
It's like a stream of someone's consciousness.
I used to take pride in being fluent in PCRE, as well as some other dialects, and looking through an old Perl script you easily see why, it's used on every 10th line. And it always strikes me with a sense of relief when I realize all those instances of Regex are solved in a more OOP/Pythonic way today. Regex is something I reserve for edge cases.
A classmate who introduced me to Linux in the early 2000’s was a Perl enthusiast who completely embodied the RTFM mindset. If someone didn’t already know something they were mocked. We ceased to be friends after a number of these interactions.
The documentation for something may not exist, may not be clear, or may just be wrong. Unless you specifically know the answer to a question is laid out clearly in the documentation, blindly telling someone to read the documentation is just being a dismissive asshole.
A much more productive and helpful response is "did you RTFM?" or "check section X of the manual". But those sorts of questions require the desire to not be a dismissive asshole.
The cult of RTFM has always been an impediment to Linux becoming more popular. When I was first learning Linux...almost thirty years ago now...the cult of RTFM nearly put me off the whole endeavor. I was asking for help with "Xwindows" on IRC and the responses were either RTFM (which I had done) or pedant diatribes about "it's X, not Xwindows newbie! It's not micro$oft!" Which was a super fun to deal with. The experience steeled my resolve to at least ask someone if they read the manual before assholishly telling them to do so.
C is also a significantly stricter language in some ways than Perl, due to its static type system, despite that type system being primitive. C, ironically, is in some ways way stricter than Rust, since it has a goal of simplicity in its language, and thus writing compilers for it (despite its ancient syntax) and standardizing it is much easier than for Rust. And those properties are rather good for a systems language. Simplicity in the language does of course not generally necessarily translate to simplicity in the code, the ability to create good abstractions is worth a lot.
Rust has also experimented with editions. And there is the issue of Rust allowing backwards compatibility to be broken regarding type inference AFAI recall, in part leading to the 1.80 time crate debacle.
This was all also at a time when Perl 6 was first starting to emerge from the vapor. The extremely wishy washy and decade long development track they put themselves on finally destroyed any notion of ever even returning to Perl. It served as the motivation to hoist all my old Perl code into ruby code.
And I specifically remember when they fixed it there really were some people who pushed back against the change. Kind of unbelievable but it's true. I guess psychologically they felt that it was unfair that they had to struggle and future people wouldn't have to. But they couldn't just say that so they came up with nonsense technical objections.
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.
Perl was horrible to build, IMO, and seemed to require 100s of options to be selected which would mean that some script would or would not run with that particular build of Perl depending on what you chose.
Python had a more clunky but still excellent regexp package, it was a doddle to build and most of the things that affected compatibility were things you could install after the python executable was built and installed - i.e. users could get their code to work more reliably.
PHP emerged as a separate language and community and "ate Perl's lunch" when it came to the dominant growing app style of the Aughties... web pages and apps. Had PHP instead been a Rails-like extension of Perl for the web, sigils would have reigned for many years more. But there was never a WordPress, Drupal, or similar in Perl, and no reason for anyone who wasn't already highly connected to the Unix / sysadmin community to really give Perl another look.
By 2005 if you weren't already deep into Perl, you were likely being pulled away to other communities. If you were into Perl, you were constantly lamenting why newbies and web devs weren't using your language, just like the DECUS and VMS crowd did a decade earlier as Unix and Windows consumed all the oxygen and growth opportunities in the room.
Nowhere in that decision-making process is there the consideration of if it's actually a good language, more efficient, more flexible, more powerful, faster, etc. It was ease of use and "the cool kids are using it".
Because of this, in practice, the amount of system administration mantainence and care needed for perl programs is far, far less than other languages like python where you actually do have to go in and re-write it all the time due to dep hell and rapid changes/improvements to the language. For corporate application use cases these re-writes are happening anyway all the time so it doesn't matter. But for system administration it's a significant difference.
I agree that python versioning and especially library packaging is the worst part of the language, though.
I've met many time some error "haha nope, wrong version, perl 5.31.7 required"
Modules with C extensions have to be recompiled with libperl they run against, as much as CPython extensions link to a particular libpython, and guess Ruby is the same. But they, with very few exceptions, will recompile and run fine. XS is cryptic but its backwards compatibility story is good.
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 strong cultural pressure to be able to write perl in as few bytes as possible, ideally as a CLI one-liner. Books[1] were written on the topic.
https://www.thriftbooks.com/w/perl-one-liners-130-programs-t...
Hard disagree. Many Perl programmers enjoyed engaging in code golf (always just for fun, in my experience), but in my nearly 30 years of programming Perl, I never encountered anything that I would call pressure to do so -- not from anyone.
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.
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.
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.
Support in forums and such was needlessly short in using RTFM as an answer. People could have pasted a one paragraph pointer to the documentation intake path and that would have helped.
IRC being async if the client is run locally, modem delays made no difference (just as with QWKmail and forum posts). And for remote host IRC, I don’t remember what the IRC line length limit was but at 300bps you could get an entire message and the buffer scroll updates accompanying it in 1 second, which was well-sufficient enough to support peak volume with no relevant latency. And, I can still type a paragraph at clock seconds of input latency and remember where I’m at when backspacing. So, I would definitely not ascribe a desire for brevity as an outcome of modems.
I wonder how common my experience was and why the next gen (at the time) I was part of never learned it
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)
In tests, you can use monkeypatching as a quick way to mock, but typically, you use modules that wrap up the functionality and make it cleaner. The mocks get cleaned up on scope exit.
There are also more principled ways of having composable behavior, such as <https://metacpan.org/pod/Class::Method::Modifiers> (advice/method combination).
There is another approach that takes advantage of the variety of scoping approaches Perl has. If one uses `local`, it indicates the use of dynamic scope rather than the standard `my` lexical scope. This can be used for things like setting an environment variable temporarily and automatically reverting it when leaving the scope. But this is not common.
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.
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
In effect, the core principles of the company (or at least, the development team of the company) end up informing which programming language to use.
That's a rather glamorous piece of discourse, yall aint sleepin
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 think instead the biggest reason PHP took off was it had far less deployment friction and better aesthetics than Perl did on machines where you didn't have admin access, basically ever shared web hosting ever.
Typically CGI scripts on shared hosting were limited to explicit cgi-bin directories that had +ExecCGI. At the same time hosts would often not enable mod_rewrite because it could get computationally expensive on hardware of the era.
This all meant that all your dynamic content had to live at some "/cgi-bin/" path. It could be difficult to have a main landing page be dynamic without an empty index HTML just having an HTTP-Refresh meta tag to your "/cgi-bin/" path.
Contrast with PHP which would be processed from any directory path and was its own built-in templating language. It was also usually included in the DirectoryIndex list so an index.php would act as a directory index leading to cleaner URLs.
In the era when deployment mean MPUT in an FTP client those small differences made a difference for people trying to make their first dynamic website and look "professional".
Wikipedia says that this source [1] claims early versions of PHP were built on top of mod_perl, but I can't access the archive right now for some reason so I can't confirm.
[1] https://web.archive.org/web/20130625070202/http://www.theper...
If Perl had had a good culture, then conserving it would have been good!
But once you get it, its pretty intuitive to use.
The worst part about it was the syntax for object oriented programming, which in raku (perl 6) is a lot better and intuitive.
Raku has some great ideas like grammars, but has a lot of new magic symbology and lost what i thought was an intuitive way of regular expressions in Perl 5.
=~ vs ~~
If only I had a dollar for every time I’ve seen this message.
In my recollection perl6 helped kill it by making perl5 stagnate, but hopefully it would have died regardless.
This was not the best when it came to others (or even yourself 6 months later) reading the code. But it was great for cranking stuff out that was simply too tedious in other languages.
I feel it only gained any web traction in the sense that it was widely available and already there in the early cgi-bin approach.
On the last comment, I've taken to using Deno/TS for most of my shell scripting type tasks these days. In general it's worked very well for me.
Also, PERL allows you to write the most unmaintainable code I've ever seen. I ran across a single line of PERL that would read a buffer, do some simple data transformations, add framing information (some of it derived from the data like length, data type, and checksum), and then write out the completed buffer.
It was beautiful. And also completely unmaintainable. Even the guy who wrote it didn't remember how it worked and had to fiddle with it for twenty minutes before he remembered a variable he used was getting set as a side effect of something else later in the line. That's great for a programming contest, but not so much for production code you may be tasking a newly minted software developer with maintaining.
Granted, you can write maintainable PERL code. But over the years the PERL has been hands down the least maintainable in different jobs and projects.
Perl wasn't arcane on purpose, the bar for being a programmer was just that much higher, born through necessity as we didn't have as much material to easily turn someone into a capable engineer, so to make anything work you had to -really- be motivated to learn, and that extended to the entire skill tree of things that happen before learning to code, like simply navigating the machine and being able to reach the realization that you needed to write something on your own.
Perl evolved to suit the needs of those that used it at the time, and it reflected their interests, skills, and abilities.
These days everything is so abstracted, so available, so easy, all of the material to learn literally anything is free and at your fingertips, programmers don't need to be that knowledgeable to identify a need and generate some code that mostly addresses that need.
But Perl specifically came out of a fairly arcane sysadmin-y corner of the world full of other already-arcane tools like awk and sed. And those were a decade older, but by the late 80s they weren't the only thing around to compare to.
And serving it tends to be "copy the files to your web server's public dir".
PHP's success and Perl's decline was obvious at the time.
One of the few insights in the blog post that aren't stupid, fake, inconsistent and schizophrenic, is the one about PHP's common approach regarding spinning up new processes.
PHP has a much bigger legacy of web stuff than Perl, because it was so much easier to use. But there's no future in it. Wordpress, Drupal, Joomla... all had their time but it's all in the past.
RoR helped Ruby push off its inevitable demise for a while, but it's going the same way as Perl. Python got lucky that it's become the defacto choice for everything ML.
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.
To me it seems that some in the Rust community in particular, perhaps because they're just the most vocal, are tightly coupled to progressive, social activism.
I guess in general I just find myself wishing that political and social issues could be entirely left out of technical communities.
Why crusade using the resources of a technical community though? Surely it alienates the people who don't happen to align with the causes important to you.
There are myriad ways to perform your civic duty in your city. You could knock doors and encourage people to vote, for example. Why do it through a technical community?
I'm a white man, and I have never felt "alienated" in so-called progressive spaces.
Why is there no outreach to other minorities in tech, like the Amish, for example? They are certainly more underrepresented than women in the python community.
Or how about male ballet dancers? Why isn't the python community allocating some of its resources to helping them feel seen and included?
I'm giving ridiculous examples because the whole premise is ridiculous. And my general question remains: Why devote the resources of a tech community toward one social issue/group or another? There are plenty of other outlets more suitable for doing our civic duty.
Well the amish wouldn't want the outreach, because they're amish.
> There are plenty of other outlets more suitable for doing our civic duty.
I kind of hate this mentality, because there's no logic or reasonableness behind it.
There's ALWAYS another place you can do something. Always. Where you draw the line is arbitrary. There's no rulebook anywhere saying we can't do this in tech. That's just your opinion, that you made up. We don't have to do that and, evidently, we don't.
It doesn't feel like I've missed out.
Why did it have to take over the world anyway?
Because it was there, mostly. In a UNIX world where text was everything, it was well suited to quick and dirty solutions (that then morphed into long-term technical debt). Most alternatives at the time were not there by default as they either were commercial or otherwise didn't have any ecosystem to expand it's utility (like CPAN - without it Perl would likely be like awk - a fully capable language, but only used for one-liners 99.999% of the time).
I never got the impression that perl's goal was to take over the world, but it was good at dealing with certain kinds of problems at a time in computing where it mattered, especially for one-offs.
The 1980s/1990s was full of many, many different data formats in a time before XML/JSON, often by long dead companies. Many a tech person was in a situation where "Oh fuck, how do I get this data out of some obscure database or other data format from some dead company that only ran on SCO UNIX or whatever into SAP/Oracle/etc" only to see somebody else already done it and made a CPAN module.
It also became an early CGI workhorse because, quite frankly, it was just there until much cleaner web-native languages started to show up.
Anecdotally, as part of some corporate lawsuits that involved stuff going back decades, a former colleague of mine recently had to grab ancient data for an insurance company from backup tapes that were last accessed in the 1980s (apparently getting readers for them was its own story). The only google results he could get for the data formats stored on them were literally usenet posts from the 1990s of people discussing working with it and...some CPAN modules somebody wrote to export it. He did chuckle when for the first time in his life he used tar without the -f switch, though.
Yeah, it's more like the article is implying that should be the goal.
In late 80s and early 90s professional knowledge was way harder to get. Learning required significant devotion, and often was obtainable through experience only, and at the same time computer-related work wasn't as well-paid as it will become later. And had controversial social standing. Like, my brother said "It will hurt your chances with girls, bro!" when I told him I want to be a programmer, and with typical sibling-love added "This, and your ugly face of course".
RTFM emerged naturally with all of these: people paid with their time and social life for this knowledge, and wrote down what they found in manuals, most often for free, and you can't just bother to read them?
FWIW most BOFH types in my memory were C programmers, and early Linux UGs. Perlists in comparison were mild, and way more open (Perl community included biologists, linguists, and other non stereotypically computer people).
Perl decline was to some extent a cultural thing. But absolutely not the culture the author means. In Perl Larry Wall promoted a sort of expressive style of writing code where you can chose between several compiler-equivalent ways to implement logic: There is More Than One Way To Do It (aka Tim Toady) principle. The alleged reason is that the choice you make conveys some subtle nuances of your thinking which 1) gives you more comfort while coding, 2) gives potentially more information to someone who will read your code. This was outrageously contrary to the mainstream tendency of commoditization of software development (and software developers) which started to gain the steam at those times. Managers wanted (and I guess still want though to the date the idea mostly failed) THE one and only right way to code each task, peferrably with the only one language (with Java as the main contender), standard training programs, and certifications - all across all domains, and as a result replaceable and transferrable coders. Perl was clearly unfit for this perfect future with its proud selection of 4 or 5 implementations of OOP, and it hurt the language promotion a lot. And then there was disastrously optimistic declaration about soon-to-be major uprgade to Perl 6 which in reality will take 15+ years, all while lots of interesting things happening outside.
I remember reading those BOFH stories because I thought it was how you became a cool technical person at the time, but never figured out why he was so angry. Eventually I realized it's because he was Gen X and in academia, so they probably had no money and all had lead poisoning.
Its main achievement is being there first, before everyone else, to run server-side code in a scripting/interpreted language.
The rest wasn't neither cultural nor technical. From a purely business perspective, having to fight against an idiosyncratic tool half the time doesn't really make much sense.
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.
Regardless of the culture issues, it was effective!
Turns out it doesn't really matter what domain you were originally trying to tackle. If you've stumbled upon a low friction way of achieving other things, people are going to use your tool for those things, even if it's not the optimal tool for those domains.
I dread the JS/TS future, but it's obviously coming.
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
Python 3 almost killed Python.
It's normal. Once a community loses faith, it's hard to stop them from leaving.
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.
Perl was effectively "dead" before Perl 6 existed. I was there. I bought the books, wrote the code, hung out in #perl and followed the progress. I remember when Perl 6 was announced. I remember barely caring by that time, and I perceived that I was hardly alone. Everyone had moved on by then. At best, Perl 6 was seen as maybe Perl making a "come back."
Java, and (by extension) Windows, killed Perl.
Java promised portability. Java had a workable cross-platform GUI story (Swing). Java had a web story with JSP, Tomcat, Java applets, etc. Java had a plausible embedded and mobile story. Java wasn't wedded to the UNIX model, and at the time, Java's Windows implementation was as least as good as its non-Windows implementations, if not better. Java also had a development budget, a marketing budget, and the explicit blessing of several big tech giants of the time.
In the late 90's and early 2000's, Java just sucked the life out of almost everything else that wasn't a "systems" or legacy big-iron language. Perl was just another casualty of Java. Many of the things that mattered back then either seem silly today or have been solved with things other than Java, but at the time they were very compelling.
Could Perl have been saved? Maybe. The claims that Perl is difficult to learn or "write only" aren't true: Perl isn't the least bit difficult. Nearly every Perl programmer on Earth is self-taught, the documentation is excellent and Google has been able to answer any basic Perl question one might have for decades now. If Perl had somehow bent itself enough to make Windows a first-class platform, it would have helped a lot. If Perl had provided a low friction, batteries-included de facto standard web template and server integration solution, it would have helped a lot as well. If Perl had a serious cross-platform GUI story, that would helped a lot.
To the extent that the Perl "community" was somehow incapable of these things, we can call the death of Perl a phenomena of "culture." I, however, attribute the fall of Perl to the more mundane reason that Perl had no business model and no business advocates.
People were being crybabies; the critics were extremely vocal and few. Python 3 improved the language in every way and the tooling to upgrade remains unmatched.
Organizations struggled with it but they struggle with basically every breaking change. I was on the tooling team that helped an organization handle the transition of about 5 million lines of data science code from python 2.7 to 3.2. We also had to handle other breaking changes like airflow upgrades, spark 2->3, intel->amd->graviton.
At that scale all those changes are a big deal. Heck even the pickle protocol change in Python 3.8 was a big deal for us. I wouldn't characterize the python 2->3 transition as a significantly bigger deal than some of the others. In many ways it was easier because so much hay was made about it there was a lot of knowledge and tooling.
They should've just used Python 2's strings as UTF-8. No need to break every existing program, just deprecate and discourage the old Python Unicode type. The new Unicode type (Python 3's string) is a complicated mess, and anyone who thinks it is simple and clean isn't aware of what's going on under the hood.
Having your strings be a simple array of bytes, which might be UTF-8 or WTF-8, seems to be working out pretty well for Go.
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.
Being more or less forced to decode that series into a string of text where appropriate made a huge number of bugs vanish. Oops, forget to run `value=incoming_data.decode()` before passing incoming data to a function that expects a string, not a series of bytes? Boom! Thing is, it was always broken, but now it's visibly broken. And there was no more having to remember if you'd already .decode()d a value or whether you still needed to, because the end result isn't the same datatype anymore. It was so annoying to have an internal function in a webserver, and the old sloppiness meant that sometimes you were calling it with decoded strings and sometimes the raw bytes coming in over the wire, so sometimes it processed non-ASCII characters incorrectly, and if you tried to fix it by making it decode passed-in values, it start started breaking previously-working callers. Ugh, what a mess!
I hated the schism for about the first month because it broke a lot of my old, crappy code. Well, it didn't actually. It just forced me to be aware of my old, crappy code, and do the hard, non-automatable work of actually fixing it. The end result was far better than what I'd started with.
I'm suggesting a model in which one interpreter runs both Python 2 and Python 3, and the underlying types are the same, so you can pass them between the two. You'd have to know that "foo" created in Python 2 is the equivalent of b"foo" created in Python 3, but that's easy enough to deal with.
Not without enormous and unnecessary pain.
The only difference was that by the time of Python 3, Python programs were orders of magnitude bigger so the pain was that much worse.
But at the time, that elite and esoteric language drew me and many others to it in much the same way that *BSD and arguably even Linux did. The way that programming computers in general did.
It wasn't a pleasant vibe that anyone should strive to recreate, but Perl was something that felt cool to many nerds back then. Perl's decline being cultural is a good thing: it's because the industry grew and matured.
The only thing I kept using Perl for over a decade was RADIUS (we ran Radiator, which was arguably the most insanely flexible AAA server for ISPs)
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.
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
The OP’s theory that Perl 6’s radicalism allowed Perl 5 to be conservative sounds right to me.
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.)
A good article, but there is nothing new about asynchronous I/O
This is a good article, but Golly, that was a faux pas!
> [...]
> 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...).
I'm a bit sceptical about this:
> (Pause a second and ask yourself about the sort of social culture that both allows this kind of behaviour at public events, and then chooses to embrace it as a key piece of cultural lore)
Is it really so terrible that someone throws a coffee cup or two at a wall to make a point? Sounds a bit pearl-clutching.
I still remember spending time with my coworkers on bench outside of building trying to figure out #@$%$^&$%@something = []sd[dsd]@$#!&lala lines written by previous developers
I was aware of ActivePerl and quite liked Komodo. Thankfully I could keep myself from doing things on Windows/IIS apart from a brief stint writing a single file CMS in ASP.
as backend we had oracle. at first we tried oracle/linux (just released). but we never managed make it work (oracle engineers that came to us failed as well). So we got dedicated sun server for it.
One day I was bored, installed mysql on my workstation, made a changes in couple of queries and all of sudden i got x20 performance of sun box with oracle. Lead developer said that it's bad solution as mysql doesn't properly supports referential integrity (we didn't actually used it in oracle iirc)
The original intent was you could see var types with them - $scalar, @array, %hash.
They immediately broke this by deciding the sigil would apply to the value /extracted/ from the data structure. So you declared array @foo but accessed an element as $foo[1]. What? There’s a logic there but already you’re violating many people’s expectations so why even have them. The sigils are now confusing many people instead of clarifying anything.
The sigil idea then /completely/ failed when they introduced references and “complex data structures” (nesting arrays within arrays like every other language - in Perl this was a special thing because they had been flattening lists by default so no way to put one inside another).
So now to get at a hash in a hash you used not % but $ since a reference is a scalar. $hash1->$hash2->{“key”}. Versus $hash3{“key”} for a simple hash. Just awful noisy syntax. Due to poor language design up front.
I never wanted to have to reason my way through chasing pointers through nested hashrefs again.
Technically you are allowed to use % like so: %{$hash1->{“hash2”}}. Which, just - lol.
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.
Python says you know nothing, but want to automate a small task. The community will help you. More so than any other language.
Then again, Python 2 and Python 3 are two different languages.
Very few projects are willing to have such a massive migration.
Any one ( and I'm sure a few have tried) can fork 2.x and keep using it.
3.x is remarkably easy , you can probably onboard a non programer to Python in a month.
They have tried and succeeded: https://docs.activestate.com/activepython/2.7/
I still consider the result "broken".
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.
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.
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
That is not what I was getting at. What I was saying is that, if you write code for perl 5.20 and mark it "use 5.20.0;", then that's it, you're done, code never needs to change again. You can bring in newer perl interpreters, you can upgrade, it's almost certainly not going to break.
You can even write new code down the line in Perl 5.32 which wouldn't be possible in 5.20, and the 5.20 code wouldn't be valid in 5.32, but as they're both declaring which version of the language they're written in, they just seamlessly work together in the same interpreter.
Compared to Python's deliberate policy, which is they won't guarantee your code will still run after two minor releases, and they have a habit of actively removing things, and there's only one version the interpreter implements and all code in the same interpreter has to be be compatible with that version... it means a continual stream of having to update code just so it still runs. And you don't know what they're going to deprecate or remove until they do it, so it's not possible to write anything futureproof.
> in 2.7, surrounding parentheses are not redundant,
That is interesting, I wasn't aware of that. And indeed that would be a thorny problem, moreso than keeping a print statement in the grammar.
Fun fact: the parentheses for all function calls are redundant in perl. It also flattens plain arrays and does not have some mad tuple-list distinction. These are all the same call to the foo subroutine:
foo "bar", "baz"
foo ("bar", "baz")
foo (("bar", "baz"))
foo (("bar"), "baz")
foo (((("bar")), "baz"))They don't guarantee that the entire standard library will be available to you two minor releases hence. Your code will still run if you just vendor those pieces (and thanks to how `sys.path` works, and the fact that the standard library was never namespaced, shadowing the standard library is trivial). And they tell you up front what will be removed. It is not because of a runtime change that anything breaks here.
Python 3 has essentially prevented any risk of semantic changes or syntax errors in older but 3.x-compatible code. That's what the `__future__` system is about. The only future feature that has become mandatory is `generator_stop` since 3.7 (see https://peps.python.org/pep-0479/), which is very much a corner case anyway. In particular, the 3.7-onward annotations system will not become mandatory, because it's being replaced by the 3.14-onward system (https://peps.python.org/pep-0649/). And aside from that again the only issue I'm aware of (or at least can think of at the moment) is the async-keyword one.
> And you don't know what they're going to deprecate or remove until they do it
This is simply untrue. Deprecation plans are discussed in public and now that they've been burned a few times, removal is scheduled up front (although it can happen that someone gives a compelling reason to undo the deprecation).
It's true that you can't make your own code, using the standard library (which is practically impossible to avoid), forwards-compatible to future standard libraries indefinitely. But that's just a matter of what other code you're pulling in, when you didn't write it in the first place. Vendoring is always an option. So are compatibility "forward-ports" like https://github.com/youknowone/python-deadlib. And in practice your users are expecting you to put out updates anyway.
And most of them are expecting to update their local Python installations eventually, because the core Python team won't support those forever, either. If you want to use old FOSS you'll have to accept that support resources are limited. (Not to mention all the other bitrot issues.)
perl 5.8 was released in 2002. perl 5.000 (there is no perl 5.0) was released in 1994. I have difficulty accepting you have perl "5.0" installed.
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.
Python doesn't use semver and never claimed to do so, but it's probably worth treating "x.y" releases as major versions in their own right (so like 2.7 -> 3.0 is a major version and so 3.10 -> 3.11). If you do that, the versioning makes a bit more sense
My feeling is the current suite of LLMs are "not smarter than US" they simply have far greater knowledge, unlimited focus, and unconstrained energy (modulo plan/credits/quotas of course!). I can't wait for the AIs that are actually smarter than us. Exciting to see what they'll do.
There was something about scaling usage in large teams that felt awkward and high friction.
Hey me too exactly! I wrote the CMS for mlb.com in 2003 entirely in mod_perl.
This post is indeed a little walk down memory lane of the Perliness of the 1990s. I spent most of the 1990s enforcing everyone in my team (yes, by 1998 they made me in charge, totally inappropriately) use Perl on awkward environments like Windows NT because giving in to horrendous systems like Active Server Pages or...shudder...Cold Fusion represented the heat death of the profession. Microsoft was determined to to murder the whole "RTFM / TMTOWTDI" culture and replace it with their own brand of corporate mediocrity (remember, there was no XBox at this time. Github? no, source control was in Visual Source Safe [narrator: your source code was, in fact, not very safe!]. MSFT was 1000% uncool and evil).
But ultimately mod_perl's decline was technical! It's syntax, organization and operation were enough to get us through the 90's but were at the same time doing violence to one's cognitive facilities. Python came along and fixed everything that was wrong with Perl. I started in Python porting things from Perl, like HTML::Mason, because I was not yet enlightened enough. But I got there eventually.
As things became more homogeneous, and furthermore as other languages also could do that “one weird trick” of cross platform support, the shortcomings of both Perl and its community came to the fore.
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.
What Killed Perl?
When I first started using Ruby after years of Perl, it felt familiar but everything was just more... sensible.
maybe its painful for guys to admit that languages could be a lot better designed, and when such langauges appeared, everyone flocked to them.
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.
I enjoyed the article but it was a nightmare to read on my phone’s browser