I always found the Perl "community" to be really off-putting with all the monk and wizard nonsense. Then there was the whole one-liner thing that was all about being clever and obscure. Everything about Python came off as being much more serious and normal for a young nerd who wasn't a theater kid.
I'm having to pick up some perl now, and while I don't interact with the community, it surely _feels_ like it was written by wizards, for wizards. Obscure, non-intuitive oneliners, syntax that feels like it was intentionally written to be complicated, and a few other things that feel impossible to understand without reading the docs. (Before everyone jumps on me - yes, as a developer, I should be able to read documentation. And I did. But until I did so, what the code was doing was completely opaque to me. That feels like bad language design.)
Some of it I recognize as being an artefact of the time, when conciseness really mattered. But it's still obnoxious in 2025.
The whole thing reminds me of D&D, which is full of classes & spells that only exist in modern D&D because of One Guy who happened to be at the table with Gygax, who really wanted to be a wuxia guy he saw in a movie, or because he really wanted a spell to be applicable for that one night at the table, and now it's hard-coded into the game.
Perl has always “flowed” for me and made mostly intuitive sense. Every other language I’ve had to hack on to get something done is a struggle for me to fit into some rigid-feeling mental box.
I understand I’m the weird one, but man I miss Perl being an acceptable language to pound out a quick program in between “bash script” and “real developer”.
I think if you were a sysadmin and used to shell scripts, sed, awk, grep and xargs then perl probably made more sense than if you were a programmer from a more traditional language coming into the perl world.
As somone that switches between both roles, when doing DevOps (aka sysadmin in 21st century) even though there is more stress regarding dealing with infrastructure, there is a certain peace of mind being away from Scrum, Jira, milestones, and other stuff, versus plain shell scripts, sed, awk, grep and xargs, VMs up and down.
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.
As another “devops-y” guy (I’m essentially a sysadmin, but i accept whatever job title is trending right now) i agree on everything. It’s nice to see (from a distance) all the bs developers have to endure on a daily basis knowing it doesn’t affect me much.
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.
>I think if you were a sysadmin and used to shell scripts, sed, awk, grep and xargs then perl probably made more sense than if you were a programmer from a more traditional language coming into the perl world.
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.
That makes a lot of sense. After 30+ years of programming, I still have to do a search (or use an LLM) to do anything useful with sed, xargs, etc. Perl never really clicked with me either.
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.
If you are familiar with all of these but not C or Java or some other "traditional" programming language, then yes, I think anyone would guess you were a sysadmin. This was the type of background GP was talking about - people familiar with shell scripting but not any other programming language, who come by Perl for the first time.
It's been a while, but I found for me personally, that Perl flows while writing it, but stops flowing when reading the same code after some time has passed. It was good for getting things done once, but no fun to maintain and adapt - at least the way I was using it decades ago. I moved from Perl to Python and never looked back.
If you’re in the market for fun hackable tool that sits between “bash script” and “real developer” I highly recommend checking out babashka.
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!
a different approach is to replace bash altogether and switch to modern shells like fish, elvish, murex, nushell (not stable yet afaik) or oils (very interesting approach, it has a bash or sh compatible mode and another one with a more modern and cleaner syntax).
I agree. Perl made sense as a “step up” in the world of *sh and awk.
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.
Was Perl one of your first languages by any chance? I freely admit that I've only been poking at it for a few months; maybe by this time next year, I'll be boggled at the comment I left, like it was written by a different person.
> in between “bash script” and “real developer”.
One of my coworkers gave me some great perspective by saying, "at least it's not written in Bash!"
Yep, first language I learned. And since I was somewhat early to the Internet thing, I found IRC when I was about 14 years old and actually learned from a lot of the folks who have authored books on Perl or are at least (were) well known in the community.
It certainly was the major factor in how I connected the dots!
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.
Not the person you replied to, but I thought the same thing. Perl was my first as well, and it certainly shaped the way I think about coding. It made Python feel too rigid and Ruby feel familiar. There's something to be said for the restrictions of an environment when you're learning how to operate in a domain that seems to shape future thinking.
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.
> There's something to be said for the restrictions of an environment when you're learning how to operate in a domain that seems to shape future thinking.
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.
Reading the YCombinator link there's a mention of APL and a comment by dTal[1] which includes saying:
> "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 }
and whoops that doesn't work; this notation brings to the focus that sum has to start with 0 and product has to start with 1 to get the right answer and you can wonder mathematically why that is; APL notation hides that just like it hides the looping. Different notation is a tool for changing the what people think about - what things we must attend to, cannot attend to, and what new things a notation enables us to see. dTal's next reply:
> "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]
In C# that task is str.TrimStart() and I assume it's a loop from the start of the string counting the spaces then stopping. Calculating length - num_of_spaces, allocating that much memory for the new string, copying the rest of the string into the new memory. I wouldn't think it was do-able using the same higher order function (\ scan) from a running sum. What this is doing to achieve the answer is different:
{⍵≠' '} ' 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
└─────────┘
Now how do I remove the leading 0s from a numeric array? In C# I can't reach for TrimStart() because it's a string only method. I also can't assume that there's a named method for every task I might possibly want to do. So I have to come up with something, and I have no hints how to do that. So I have to memorise the TrimStart() name on top of separately learning how TrimStart() works. That notation gives me a clear readable name that isn't transferable to anything else. In APL it's:
{⍵/⍨∨\⍵≠0} Dv # Remove leading zeroes [from a numeric vector]
That's the same pattern. Not clear and readable, but is transferable to other similar problems - and reveals that they can be considered similar problems. In C where strings are arrays of characters, you aren't doing whole array transforms. In C# strings are opaque. In APL strings are character arrays and you can do the same transforms as with numeric arrays.
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.
> It made Python feel too rigid and Ruby feel familiar.
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.
i think this is changing. in recent years, alternative shells that break with bash syntax like fish or elvish and others are gaining in popularity. oils is of particular interest because it has an sh/bash compatible mode and thus provides an upgrade path away from bash.
There’s nothing that can replace bash for what it does. People have been trying for decades. You’ll be happier if you accept that bash can and will happily coexist with anything and everything else, which is exactly why it will never go away.
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.
CLI usage revolves around text and bash is a meta layer above that. Given curl, jq, and awk, you can create a quick MVP client for almost any api. Doing the same in Python and Go is much more involved.
I wrote a ton of Perl 5 and also found it very intuitive and powerful. I think the notion that Python is "more readable" is true, but also less useful of a metric than it would seem. Python is still gibberish to a new coder and requires training and experience to master. Perl requires somewhat more effort to acclimate to, but ultimately is much more expressive and much closer to real-world software engineering problems. Once the incremental effort is made, Perl is (or at least was) a better Python.
> Some of it I recognize as being an artefact of the time, when conciseness really mattered
It was an artefact of bursting out of those constraints, but honoring them still. The roots of perl as a “more capable, less restrictive” sed/awk means that it must support `perl -pi.bak -e oneliner file`, just like sed did — and so from that core requirement forward, everything it did, does. By the heyday of Perl5 era, conciseness was not a requirement, but the sed-compat roots remained a focus of the language’s creator.
It isn't bad language design that you need to study the language before you can use it. I look at haskell programs and it looks mysterious to me because I haven't spent any time studying it, but I'd not thing to say it is bad language design.
Yes, one can write obscure perl code and some love perl golfing. In the same way there is an IOCCC which delights in unreadable code, it doesn't mean that the C language should be relegated to the dustbin. The answer is to write readable code, no matter which language is in use.
To be able to fully comprehend Perl (even without having to embrace it), one needs a fiddle.
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 `$_`?
$_ follows the spirit of shell variables (such as $*, $@, $! etc., heavily used in Korn, Bourne flavours but not the C flavours), but was repurposed or – more likely – picked from a pool of vacant characters with the help of a dice roll. Kind of like how ancient Egyptians built the pyramids with the help of sophisticated cranes and machinery and then vapourised their tools with high-particle beams to leave future generations guessing «how on Earth did they manage to do that». This is one of the main criticisms of Perl.
- What is this BEGIN block at the start of this Perl file? Why is that necessary?
Perl started out as an improvement over «awk», and BEGIN is an awk construct where it is used frequently, e.g. awk 'BEGIN { IFS=":" } { … do something … }'
- What does chomp do when it's just on its own line, with no arguments given to it?
It follows the standard convention of UNIX utilities that expect the input to come from the standard input stream (file descriptor 0 or <file-in in the shell) when no input file name has been specified. So, when no <FILE1> given to chomp, it chomps on the standard input.
Again: python syntax is more akin to what you are used to, and so it feels more comfortable to you.
$_ is inscrutable if you haven't studied perl, but the same thing would happen to anyone who sees a python decorator for the first time. what does "else: do after a while loop in python? Only people who know python know what it does (and I suspect most don't). The different quoting operators are also trivial to learn. In comparison, yield from python is also simple syntax but the semantics are much more involved.
BEGIN? Take 60 seconds to read what it means. And if you knew awk, you'd not have to do that, as it was directly lifted from awk.
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.
It could've easily been defined that the else branch runs if the while condition never had a true value at all. In fact, I think that's more intuitive.
It's not just a matter of "read the docs", though, because languages can differ in how many distinct concepts/constructs they employ. Python has gradually added more over the years but still I think is well short of Perl in this regard.
Given python’s love for string-leading sigils, the previous commenter should be quite comfortable with the idea of obscure single-letter operators that dictate the interpretation of the following tokens.
If you think that's bad, try learning python or a verbose language while not speaking english, all of these words like while, for, if, else, break are just gibberish and your code just reeks of some weird mish mash of broken english and broken <mother tongue>, I have a hypothesis that terseness favors universality, if you don't speak english, something like $_ is equal or easier to grasp, it honestly just looks like terse and weird math.
That was the idea of APL (and its successors like J and K) -- make programming a math notation rather than pretend to be a human language (generally English, but there have been programming languages with keywords in Chinese and Russian, among others).
You’re mad that you have to look up what keywords do in a programming language you aren’t familiar with? If you think Python is always clear, I can guarantee you (as someone with relatively expert grasp of Bash, Ruby, Go, and once long ago, Perl) that no, it isn’t always obvious.
Yeah, it's true that Perl did not have as a design goal that a complete newcomer should be able to intuitively understand the code without having any prior exposure to the language. There is a little bit of a learning curve, and that was completely expected by Perl's creators. Yes, you have to learn about the idioms above, but they became second-nature. For many of us, the model clicked in our heads and the terseness was worth it. You could express a lot of functionality in very few characters, and if you had invested in learning, it was very quick to grok because common patterns were reduced to familiar abstractions in the language.
And yet, as the industry grew and all sorts of people from all sorts of backgrounds converged in this space, the tolerance and appetite for funky/terse waned in favor of explicit/verbose/accessible. It's probably for the better in the end, but it did feel a little bit like the mom-and-pop store on the corner that had weird pickled things at the register and a meemaw in the back got replaced by a generic Circle K with a lesser soul.
> 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.
Honestly, $_ and "what does a function do when I don't supply any arguments?" are really nice in Perl, and not that difficult to understand. I think a lot of languages could use a 'default variable'.
$_ was one of the things that put me off perl, because the same syntax meant different things depending on context.
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.
When I was choosing between learning python and perl in the late 90's, it was the context sensitivity of perl expressions which really squicked me. To me, that was the critically bad language decision in perl. You can make context-sensitive expressions in python (using operator overloading, for instance), but you have to go out of your way to do it in one way or another. In perl you can easily do it by accident, and it can result in serious bugs. It seemed masochistic, to me.
Seems like the essential criteria is not whether you can write opaque code in it, but rather whether the language enables you to accomplish most tasks using clear, readable code. They aren't mutually exclusive.
> I'm having to pick up some perl now, and while I don't interact with the community, it surely _feels_ like it was written by wizards, for wizards. Obscure, non-intuitive oneliners, syntax that feels like it was intentionally written to be complicated, and a few other things that feel impossible to understand without reading the docs.
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.
While I'm not a fan of Perl per se, I find it fascinating. One of the reasons for that is that its creator, Larry Wall, is a linguist by trade. This shows in a lot of ways, for example by the fact that, like natural languages, Perl has context: A variable can behave differently whether it is used in a scalar context or an array context. At the same time stuff like this is responsible for Perl's reputation as a write-only language, a cliche which has at least some merit to it.
I can highly recommend reading at least the first chapter of Programming Perl, it's highly insightful even if you don't plan to write or read any Perl.
>>I'm having to pick up some perl now, and while I don't interact with the community, it surely _feels_ like it was written by wizards, for wizards.
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.
> 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?
Do you not? The pace of anthropic/Claude tool development is pretty bonkers, AI hype reminds me of the 90s a lot.
>This was one of the big reasons, most of these enterprise coders wanted Perl gone
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
Yup, Perl is something clearly out of Unseen University, err I mean Berkeley linguistics dept.
I liked it, thought the sigils were a cute way to singal that something is a variable. When you work with deeply nested data structures, dereferencing arrays and hashes that sort of changes and becomes kind of annoying. Nowadays I like Ruby. Compared to it, Perl does feel like spells mixed with C and Posix stuff. But if I want to feel smart, I'll write some code in Scheme, thank you.
This is it.
I wrote largish systems in perl using its OO things and that was good.
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.
> 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.
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.
The term "surrogate activity" comes to mind, specifically, activities of no real value that some people like to waste time on to feel better about themselves.
> I always found the Perl "community" to be really off-putting with all the monk and wizard nonsense
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')
Perl made a mistake, the language was invested in depth of expression and that, in a programming language, just leads to a 1000 ways to write same thing where like... 2 of them are actually nice to read.
Pyton was ("was" was used here on purpose) the opposite, the whole "one way to do a thing" and insisting on more clean code even if more verbose.
You could write nice looking Perl code but you had to choose to do it, while Python pushed you in that direction from the start.
As much as I dislike using whitespace as flow control it also does make sure the code is always indented reasonably even if it is a newbie just starting in the language.
It didn't help that Perl, just like other languages after (PHP, JS, Python too), had a "curse of the newbie language", with many people starting with it (as at the time it was kinda only sensible choice for webpages before mod_php did a revolution in how most webpages are hosted), with no training and just winging it, which in language that puts no limits on what user can do and no guidance on what they should do... leads to that ugly one liners and line noise as a code scripts.
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).
That is the story that Python tells about itself. Meanwhile, folks who don’t use it every day are constantly learning that it’s only true within a single version of Python, but that over the years there will be multiple, incompatible ways to do niche wild rare stuff like … iterating over a map.
Python has never actually followed the Zen of Python, which is one of my gripes with it. For example, "explicit is better than implicit" is a bad joke given how Python implicitly treats non-boolean types as booleans.
I don’t know about the wider Perl community, but I listened to some interviews from Larry Wall and he just came across as a nerdy guy having fun with what he’s doing. I quite liked listening to him.
Larry should be remembered for the development of "patch" more than perl. Without the concept of fuzzily applying patches to modified source files you can't have "git rebase" or "git merge".
Larry was (and presumably is, but I'm out of that loop) a gem. The Weird Al of programming languages. Hilarious and kind.
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.
Maybe in retrospect instead of “this isn’t a help channel” it should have said “go to #perl-help for questions” or made #perl be an open forum and moved the wizard discussion to #perl-experts?
My anecdotal experience was with perl guys who were ex-military, irreverent, and fly-by-the-seat-of-your-pants. The Java and .NET guys were straight laced and nerdy.
Individuals are rarely (not never, but rarely) the full problem. Groups of people are what cause feedback loops and cultural reinforcement like the author describes. Sometimes this is a virtuous reinforcement cycle but more often than not the well gets poisoned over time.
I actually think it works when you are in the ecosystem fulltime for a good while.
But having to interact with it once in a while is always a hurdle. The same with bash. Do I use [ or [[? Where does the semi-colon go? if then fi, but while do done (and not elihw). -eq or =? Functions have () but no parameters.
I'm sure those things make sense when all you write is Bash / Perl, but it's daunting.
Now, Python can get pretty far out there too with Meta-programming, and JavaScript can get confusing with prototyping. And Ruby (especially RoR) takes the crown, where they resolve variables at the moment the line executes. Makes debugging blocks really hard.
>I'm sure those things make sense when all you write is Bash
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.
You realize you can learn all of this easily online, I hope? Sure it turns out that a scripting language maintaining compatibility with scripts from 40+ years ago has some confusing aspects. That’s the price of such incredible staying power.
Perl is a sysadmin language. There's "always" been this tension between sysadmins and developers.
In my mind (developer back then) I'd amateur-psychoanalyze all of that nonsense as some kind of inferiority complex meant to preserve the self image. Needless complexity can be a feature!
That quote is not very convincing to me. Both parts of it are questionable.
Just being able to play chess is not a very high bar at all. Most 6-year-olds can learn it in an hour. Are the Chess hustlers at Washington Square Park all Gentlemen?
I don't see being able to play Chess well as any kind of deficiency. It could be that it's just someone's hobby. It doesn't have to mean they spiraled into madness, Bobby Fisher style.
(I can play chess, but not well, so I personally don't care about either half of that quote as it applies to me)
I think it's a sysadmin thing to have a little bit more wimsy in the code.
Administrative work by nature leaves you a bit bored, if you do it right. So you sometimes pick something up just to play with.
I can't speak about every sysad experience, but in mine a lot of scripts tend to be in a "make once, remember for ten years" category, and even a bit of creative naming can help a long way.
Working with a larger codebase with "creative" code, on the other hand, is frustrating. And if you don't have to write code, you might as well go take a walk, "monitoring" isn't in your job description.
I think Perl is still more popular even today than Python as a sysadmin language. Late 2000s it certainly was. Maybe Google was different, but across the industry more widely Python was barely used, Perl was used everywhere.
As someone who lived through that transition, we used Perl extensively to sysadmin ~30 Solaris and Irix workstations and it was superlative at that.
At that time, Guido was still working at CNRI locally to us in Reston, VA and we had several discussions at the local Pyggies (Python User Group) on transitioning over to Python for that work. We were a (mostly) C++/Java shop, but Perl fit into all the other "crevices" beautifully.
Python just didn't have enough library support for all of our "swiss-army chainsaw" demands. Still, it was very apparent at the time it would eventually get there and I was enamored with its "one right way" of doing things--even at the bytecode level.
I never interacted with any of that, to me Perl was always "Bash with text processing built-in and no string interpolation pitfalls". I reach for it when I need to write one to two page long utility scripts. Python is too willing to deprecate features (plus the whole 2 to 3 fiasco burned me badly), so I only use it for things I know I will maintain. Perl is for writing a shell script that will run unchanged in perpetuity.
I appreciated them at the time I encountered them (mid-2000s), but they were definitely a bit cringe in their frequency and shamelessness. I wonder if younger people even know Monty Python anymore - by my time, I think people had mostly forgotten about Hitchhiker’s Guide to the Galaxy, even if 42 survived.
As a foreigner I hadn't known Monty Python when I started learning the language and reading the docs, and I haven't noticed any of those. I guess they came across as just noise.
6-7? No, my kid says it about a thousand time a day. Then, for some unknown reason they follow it with 41! WTF! I've shouted 42! many times and have tried to inform the child of the significant cultural and scientific importance of 42. Which, IIRC, factors to 2,3,7.
I agree but don’t forget that the average programmer nowadays is a strait-laced corporate entity, whose personality is Node.js stickers on a macbook, like everybody else in their team.
They forget that Perl and co. were written by people that had one too many tabs of LSD in the 70s, sporting long hair and a ponytail.
I’m going to go out on a limb and guess that Larry Wall, a devout evangelical Christian and the child of a pastor, was not turning on, tuning in, or dropping out in the 1970s.
Python for awhile had its own cultural issues. I guess, coming from more of a C and lisp background, the stuff you're mentioning seemed playful and fun to me and I didn't get the sense anyone expected to write performance critical code in it anyway.
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.
I've always found Perl just plain ugly, too clever about some things (like iterating over regex matches on stdin or something) and really dumb about other things (variable syntax, the god-awful OOP system). Python is clean and pretty in comparison and usually well thought out.
If the communities were reversed, I'd still prefer Python: I just read the documentation in 99% of cases, I very rarely need to interact with the community. Python, as the article says, is mostly not a language for fans - it's mostly for auxiliary tasks.
I liked perl, it was the first language I used daily as a HW engineer. When I moved to python more recently what I missed the most was how easy it was to do a one liner if with regex capturing. That couldn't be done in python for a long time. I think the walrus operator helps, but it's still not quite as concise, but it's closer
My code wasn't written to be hard to decipher, and it wasn't a goal to get everything on one line by any stretch, I just didn't like an if with regext was 2 lines minimum in python, it felt inelegant for a language that is pretty elegant in general
This will keep happening until we start programming computers with some kind of AI style driven interfaces, and even then maybe not.
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.
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.
oh yeah you're right and this is coming from someone who still likes/uses perl once in a while for text manipulation stuff that awk/sed won't cut it for. try going into your terminal and typing in
man 3pm Errno
And you get this code snippet:
my $fh;
unless (open($fh, "<", "/fangorn/spouse")) {
if ($!{ENOENT}) {
warn "Get a wife!\n";
} else {
warn "This path is barred: $!";
}
}
man is that ever from a different time... but let me tell you if you can pull off some of those awk/sed or perl one liners you can do some pretty useful things with less resource allocation than you would be spending if you had written that in python, which becomes important if you're running it over and over on terabytes of data or on limited hardware
> 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
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:
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 community college our perl professor was often late. One time he just didn't show up. I remember him once saying something like job security involved writing indecipherable code so none of your coworkers could understand it. There was a tinge of bitterness in his remark. Our exams were essentially obscure perl puzzles where we had to read the code and determine the output, some kind of coded phrase.
I have never worked (in Prod) with Perl, but my introduction to programming was with PHP and all I know IMHO is that PHP was/is so easy to start with. One of the reasons I picked PHP over other languages.
Strange, maybe because of being a 70's kid and a D&D nerd, that kind of stuff is exactly why I liked Perl in first place.
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.
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!
Of course it was cultural. This article covers it all in more detail, but I was coding a lot in this period of Perl's decline, and in hindsight it was all so obvious.
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.
But could a different culture have actually changed Perl to be friendly and fun like Ruby? Without completely torpedoing compatibility with existing code and essentially creating a whole new language anyway?
Or did the language itself just get outdated and replaced? (there's nothing wrong with that! most things don't last forever!)
I feel like I grokked Perl enough and I still write Perl code, but I also think that there are some technical reasons why it declined in popularity in the 2000s and 2010s. All those differences between $ % @, the idea of scalar or list context, overuse of globals, and references. These features can all make sense if you spend enough time in Perl, and can even be defended, but it creates a never-ending stream of code that looks right but is wrong, and it all seems to create a lot of complexity with very little benefit.
I never interacted with the "Perl community" described here. When I used Perl in a past job it was in the "just google for how to do things" era.
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.
> 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.
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 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.)
That's the problem! The code should not run if the types are wrong. Having an external tool is an antipattern.
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 are talking about misleading type hints, not optional ones. Optional means they don’t have to be added. Wrong typehints are so much worse than missing ones.
I think the purpose of optional type hinting is that you don't have to add it everywhere all at once, not that it doesn't have to be accurate. I guess you could split hairs and say "hint" doesn't imply perfect accuracy, but... adding a language feature that can lie really seems to have a lot of downsides vs upsides; whereas at least optional has obvious migration benefits.
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...)
> 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.
If it's built in to the runtime you get a lot of potential benefits:
- 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?
In fairness, Perl died because it was just not a good language compared to others that popped up after its peak. Sometimes people just move to the better option.
Perl is a great language, the way Scala and Haskell are great: as openly experimental languages, they tried interesting, unorthodox approaches, with varied success. "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say.
Perl is not that good a language though for practical purposes. The same way, a breadboard contraption is not what you want to ship as your hardware product, but without it, and the mistakes made and addressed while tinkering with it, the sleek consumer-grade PCB won't be possible to design.
> "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say.
Perl lets every developer write Perl in their own idiosyncratic way.
And every developer does.
It makes for very un-fun times when I'm having to read a file that's been authored by ten developers over ten years, each of whom with varying opinions and skill levels.
I guess in 2026, it'll be 11 developers writing it over 11 years. My sincere apologies to those who come after me, and my sincere fuck-you to those who came before me. :)
Something I only figured out in the ‘10s is that the main tax of code smells is during debugging. Debugging when taken to the level of art is less about sorting all of the possible causes for a problem by likelihood but by ease of validation.
Things that are cheap to check should be checked first unless they are really unlikely. You change the numbers game from trying to make the biggest cleaving lines possible, to smaller bites that can be done rapidly (and perhaps more importantly, mentally cheaply).
Code smells chum the waters. Because where there is smoke sometimes there is fire, and code smells often hide bugs. You get into Tony Hoare’s Turing award speech; either no bugs are obvious, or there are no obvious bugs.
So I end up making the change easy and then making the easy change because we have more code each week so the existing code needs to be simpler if someone is going to continue to understand the entire thing.
Perl doesn’t seem to have figured this out at all.
Exactly. Perl is about experimenting, trying things your way, and discovering new and good ways to write programs. Which is a wonderful capability for research and discovery, and for art or recreation, but not that great for industrial production.
This is why Perl was quite fit for the job at the dawn, or, rather, the detonation phase of the Internet explosion in late 1980s and early 1990s, along with Lisp and Smalltalk that promote similar DIY wizardry values. But once the industry actually appeared and started to mature, more teamwork-friendly languages like Java, PHP, and Python started to take over.
I wouldn't say "wildly". I would say that it's critical enough to the company's workings that they devote enough resources to it to keep it going, but not enough resources to consider re-writing it or re-factoring it to be easier to work on.
In a similar vein, as the industry matured, we went from having teams of wizards building products, to teams of "good-enough" developers, interchangeable, easy to onboard. Perl culture was too much about craft-mastery which ended up being at odds with most corporate cultures.
Unfortunately, as a former Perl dev, it makes a lot of other environments feel bland. Often more productive yes, but bland nonetheless. Of the newer languages, Nim does have that non-bland feel. Whether it ends up with significant adoption when Rust and Golang are well established is a different story.
Check out "Perl Best Practices" by Damien Conway, and the more recent "Modern Perl" by Chromatic. Both can be had as paperbacks, and I think both are also available free on online.
I'll go further. Ignore the Perl specific bits and Conway's "Perl Best Practices" is one of the best general programming books ever written.
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.
The big pearl of wisdom I took from Larry Wall seemed to be counter to the culture I experienced looking in from the outside. That always confused me a bit about Perl.
And that was, paraphrased: make the way you want something to be used be the most concise way to use it and make the more obscure features be wordy.
This could have been the backbone of an entire community but they diminished it to code golf.
Couldn't they have figured out one decent way to do things before releasing features to all users? I tried Scala for a bit then decided it was complicated for no good reason.
Idk about Haskell, but I used Erlang which is also purely functional. No matter how long I used it and tried to appreciate its elegance, it became clear this isn't a convenient way to do things generally. But it was designed well, unlike Scala.
Erlang is, by my accounting, not even a functional langauge at all. It takes more than just having immutable values to be functional, and forcing users to leave varibles as immutable was a mistake, which Elixir fixes. Erlang code in practice is just imperative code written with immutable values, and like a lot of other modern languages, occasional callouts to things borrowed from functional programming like "map", but it is not a functional language in the modern sense.
If you go to learn Haskell, you will find that it has a lot to say about functional programming that Erlang did not teach you. You will also find that you've already gotten over one of the major hurdles to writing Haskell, which is writing with immutable values, which significantly reduces the difficult of swallowing the entire language at once and makes it relatively easier. I know it's a relatively easy path because it's the one I took.
> Erlang is, by my accounting, not even a functional langauge at all.
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.
If you wanted to write a quick on off script then using magic variables,etc made sense. Writing something you’ll keep? Don’t use those. When Perl 5 introduced references they could have simplified the syntax though.
Not really. It wasn’t audacious in service of anything innovative. Haskell takes functional programming to the nth degree, scala tried to be an advanced Java for example better at concurrency.
Perl was an early dynamic (garbage collected) “scripting language” but no more advanced than its contemporary python in this regard.
It had the weird sigils due to a poor design choice.
It had the many global cryptic variables and implicit variables due to a poor design choice.
It has the weird use of explicit references because of the bad design choice to flatten lists within lists to one giant list.
It actually was the one thing you said it wasn’t - a good practical general language at least within web and sysadmin worlds. At least until better competitors came along and built up library ecosystems.
I think what's most likely to happen here is that:
* a developer that knew how it worked used it in code where he *wanted* to get the first line
* someone just starting up copied it over and assumed that's the way to get the content of command into a variable
It's essentially complaining about using feature wrong on purpose, because the person that made mistake never learned the language.
my($var1, $var2...) is a way to multi-assign variables from an array.
and that makes perfect sense when you look at it. Perl have no multiple returns, but if you need a function that returns 2 variables it is very easy to make it work with:
my ($bandwidth, $latency) = speedtest($host)
Perl's feature for returning different type depending on caller is definitely a confusing part but
my @lines = `fortune`
returning lines makes perfect sense for the use case (you call external commands to parse its output, and if you do that you generally want it in lines, because then you can just do
foreach my $line (`fortune`) {}
and it "just works".
Now you might ask "why make such shortcuts?". Well, one of big mistakes when making Perl is that it was also aimed as replacement for sed/awk for the oneliners, so language is peppered with "clever short ways to do stuff", and it's a pleasure to use in quick ad-hoc oneliners for CLI.... but then people try to use same cleverness in the actual code and it ends up with the unreadable mess people know Perl for.
the fact you can do
my ($first_line, $second_line, ...) = `fortune`
is just the feature being.... consistent in its use "when you give it array, it will fill it with lines from the executed command"
you gave it array, and it just did what it does with arrays.
Then don't use the low level interfaces. In Perl, language features are plug and play. Everything's in a module. Use the core module List::Util instead.
That's not super subtle any more than it's super subtle that "*" performs multiplication and "+" performs addition. Sometimes you just need to learn the language.
This is not a general defense of Perl, which is many times absolutely unreadable, but this example is perfectly comprehensible if you actually are trying to write Perl and not superimpose some other language on it.*
There's is no fair comparison to be made here with how + and * work is most languages, precisely because + and * work the same in most languages, while whatever perl is doing here is just idiosyncratic.
Even C gets it's fair share of flack for how it overloads * to mean three different things! (multiplication, pointer declaration, and dereference)
It's just very non-obvious what the code does when you're skimming it.
Especially in a dynamic language like Perl, you wouldn't know that you're passing down an integer instead of a function until the code blows up in a completely unrelated function.
You can't do that if you gave up at the very first sigil puzzle.
I'm fine with that: to program in Perl you need to be able to follow manuals, man pages, expert answers, - and even perl cookbooks, or CPAN or web searches. It's a technical tool. The swiss army chainsaw. It's worth it.
Seems like you and a few other posters are making the article's point – that Perl's culture is hermetic and that new programmers would rather learn Python, Ruby or Javascript rather than figure out which sigil means what.
I wouldn't call it hermetic in that the many forms of documentation are insanely thorough and accessible - if not well advertised. There is no gate-keeping (from my point of view). New users are welcome. It's easy to learn (for the people for whom reading is not an obstacle).
But yes, no contest that the world has been on a simplicity binge. Python won by pushing simplicity and by having giant software corporations choosing it (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.
> it was just not a good language compared to others
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.
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.
Yes there was a reason as Perl took inspiration from Lisp - everything is a list- and everyone knows how quick C's variadic arguments get nasty.
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.
Not only normal arguments like we get in C or Pascal, but there's keyword arguments, you can have optional arguments, and a rest argument, which is most like Perl's @_. And that's not even getting into destructuring lambda lists which are available for macros or typed lambda lists for methods.
Perl was (and still is) a very expressive and concise language for working with text and a unix-style system. It exists in the odd space between a shell language and a general purpose language.
But, shell scripting has already become somewhat of an arcane skill. I think the article nailed that Perl was just too hard to learn for the value it provided to survive. Python is not nearly as, erm, expressive as perl for working in that space, but it is much easier to learn, both in terms of reading and writing. In other words, it encourages broadly maintainable code. Ruby is quite similar (although I think people massively overstate how much the language itself generally encourages understandable semantics)
> Perl was (and still is) a very expressive and concise language for working with text and a unix-style system. It exists in the odd space between a shell language and a general purpose language.
GvR explicitly describes the motivation behind Python in similar terms (I can probably find a timestamp in that recent documentary for this). But the goal there was to be fully "general purpose" (and readable and pragmatic, more than artistic) while trying to capture what he saw as the good things about shell languages.
And it's changed quite a bit since then, and there are many things I would say with the benefit of hindsight were clear missteps.
We all joke about the hard problems of computer science, but it seems to me that the hard problems of programming language design, specifically (and perhaps software engineering more generally?) include having good taste and figuring out what to do about reverse compatibility.
> I think the article nailed that Perl was just too hard to learn for the value it provided to survive. Python is not nearly as, erm, expressive as perl for working in that space, but it is much easier to learn
The use cases have also changed over time. Quite a lot of developers ended up on Windows (although that pendulum is perhaps shifting again) where the rules and expectations of "shell" are very different. To say nothing of e.g. web development; long gone are the days of "cgi-bin" everywhere.
Shell is a crappy scripting language because it has primitive data structures and data flow control making it hard to manage and manipulate data as you process it between applications. The fact that newlines are such a problem is a case in point.
Python is a crappy shell scripting language because the syntax around pipe and subprocess is really clunky.
Perl managed to have decent data structures and also have decent syntax around subprocess calls.
But I feel like the Python invoke module gives me everything I need wrt subprocess calls. I basically write any nontrivial "shell script" these days as a Python invoke command.
When I learned perl, I encountered a way to express myself more easily than any other language. For example, being able to say not only "if foo" but "unless bar" gave me a more fluid vocabulary to get things out of my head and into code.
Thing is, it worked great for ME but when I started interacting with other people's perl code, it all broke down.
One person would write it all on one line. Another would be extra verbose. Some would use all the idioms, others would be 10 levels of nested braces.
Every person's brain expressed itself differently and it was much harder to find common ground.
Eventually I left perl for python, which seemed to be more sane. It seemed pythonic was more of a thing and the code was more readable. Also, it had a large standard library and you didn't have to leave the language to solve just about any problem. It did require extra effort to write code, but the benefits were pretty obvious.
A couple other sort of random points - perl 6 was delayed and that might have hurt the language. Just the same python 3 did come out, but the 2 to 3 changeover was a huge negative to the language.
Perl was my first favourite programming language, used it for most things, from 1999 until switching to Python in 2012.
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.
I was a fairly heavy user of Perl, but eventually migrated to Python. The primary reason was the generally abysmal quality of what was in CPAN compared to what was available as third-party packages for Python. I found myself having to spend way too much time fixing stuff I pulled down from CPAN far more than I'd need to for Python for the same functionality. Undoubtedly Perl stuff got better, but I didn't have time to wait.
I mainly moved on to Python because the startup time for scripts seemed to be a lot worse for Perl. I was a heavy Perl user in the 90's and early 2000's.
No. Perl died because other languages starting having an equivalent to CPAN and its extremely flexible syntax does not scale for medium to large team coordination.
It does if you restrict flexibility, but one of the critical flaws in Perl culture was the belief in letting everyone evolve in different directions while cooperating. It’s a genuinely charming belief, but it’s also explicitly incompatible with ‘interchangeable parts’ employment, and tends to only work in an environment where every individual is the ‘wizard’ lord of their personal domain over code. Even if you managed to train everyone to parse Perl, the cognitive overhead of having to train everyone in each other’s syntactic decisions was O(2^n) expensive, which contrasted quite sharply with Python moving that expensive cognitive overhead to the Proposals system while the produced language had slow version updates and “What we argued about so you don’t have to retread the same ground at work every quarter” mission briefs.
Some of the reasons why I never bothered with Perl was that I had the perception that it, like Ruby, encouraged mutating and modifying classes on the fly, willy-nilly. And the lack of static typing. Python also did not have static typing (it has some optional typing now or something like it), but my perception was that monkeypatching was not abused as much in Python as it might be in Perl and Ruby. Not that I used Python a lot.
Perk was never much interested in fiat-enforced restrictions. That was considered to be the domain of local policy in a given project or team and not something to declare upon its users. We’ve since determined in programming that restrictions can exceed the value of perfect freedom (cf. Rust, TypeScript vs. C, Perl). But for scenarios where rapid flexibility is key (eg. ops eng, sans sre/k8s/etc) the flexibility is more important than the restrictions. Always have an adjustable wrench alongside your fixed-jaws, just in case.
Regarding restrictions vs. perfect freedom, I think it's also about trade-offs, implementation quality, etc. Typescript has very easy and well-defined escape hatches. Conversely, Rust's escape hatches are an active research field, not well-defined, considered significantly difficult by prominent Rust figures, the safety is leaky (for instance no_std), etc.
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.
I switched to ruby because of the quality of the MRI for writing extensions. It was literally a revolution. No more SWIG, no more complex type magic, no more struggles to compile my module on end users systems. This was all wrapped by up gem as well so the switch was genuinely impossible to avoid.
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.
> if difficulty itself becomes a badge of honour, you've created a trap: anything that makes the system more approachable starts to feel like it's cheapening what you achieved. You become invested in preserving the barriers you overcame.
The mentality described here has always galled me. Half the reason I’m willing to scramble up these hills is to gain the perspective to look for an easier way up the next time. It’s my reward for slogging through, not for the gathering of sycophants.
I’m not sure you’ve mastered a thing until you’ve changed the recipe to make it a little bit better anyway. My favorite pumpkin pie recipe, isn’t. As written the order of operation creates clumps, which can only be cured with an electric mixer. You shouldn’t need an electric mixer to mix pumpkin pie filling. If you mix all the dry ingredients first, you get no clumps. And it’s too soupy. Needs jumbo eggs, not large. So that is my favorite recipe.
But maybe this is why I end up writing so many tools and so much documentation, instead of hoarding.
Perl was of a time, so it's important to remember when it was around. CPAN was legitimately one of the first package managers for a programming language that WORKED. Contextually, its references are bash, sed, awk, and other cli tools. There are too many ways to do things in perl because of the various flavors / takes on how to do things. It was also a fun way to write cgi apps in the era of C/C++. Is that the best way to do things today? No! It was one way to do something complex in few lines of code. It was the python of its day in many ways.
There are tons of quirks that are interesting that influenced language development today, for me the spaceship operator "<=>" was a fun one. You can have a flip through the camel book to see what kind of stunts were common in its era.
It is an auteur language that was not really done the way languages are today.
Perl 6 did massive damage to the community mainly because it was so different that it looked like a fantasy language. That along with Parrot really lost the plot for me, I had mostly stopped doing that kind of work and moved on to R for my bioinformatics things. Bioconductor was the bees knees.
I'm surprised at all the haterade, probably you're either <30, and/or being overly critical of a very nascent tech era. Perl was pre and post .bomb, and had one of the first online communities that I remember that shared tips and tricks at scale at perlmonks.org. It predated stackoverflow! It was a very different time to now.
This was also from a time when people still paid for compilers(!)
I am deeply biased, as I wrote a 3d distance calculator in Perl for small molecule drugs. We were looking for disulfiram analogs doing biopanning and then simulations. There was a great PDB library for structures at that time that saved me tons of time. This was circa 2005~, ages from now.
I think it's worth pointing out that Python only became popular after Google started using it. Remember when every nerd on the web was an ardent defender of Google? When people wanted to reach for a new language (say, for data science, also a new thing at the time) they reached for that slightly obscure yet easy to learn language that the cool tech company used. Schools adopting it exposed it to more people, but they picked it up, again, cuz Google used it and it was easy to learn.
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".
There was a lot of pressure in the Perl community to write things as succinctly as possible instead of as maintainably and understandably. That’s not realistic for use in a field with a lot of turnover and job hopping.
Write-only perhaps, but with perl you only have to write it once and it'll run forever, anywhere. No breaking on updates, no containers, no special version of Perl just for $application, just the system perl.
Because of this, in practice, the amount of system administration mantainence and care needed for perl programs is far, far less than other languages like python where you actually do have to go in and re-write it all the time due to dep hell and rapid changes/improvements to the language. For corporate application use cases these re-writes are happening anyway all the time so it doesn't matter. But for system administration it's a significant difference.
Agreed! My father (RIP) absolutely loved Perl and could do amazing things with it in seemingly impossibly-few characters. I got reasonably proficient w/ regex but never came close to his wizardry. Much respect for those in his rarified company.
Pure perl modules are not, unless they use syntactic features that first appear in the newer versions.
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.
There was no such pressure. That's ridiculous. There were a lot of things people could grab as reasons to form an opinion without even reading articles, never mind the tutorial. They then ended up with php or python, even java for crying out loud, and years later THAT was a problem.
There wasn't pressure to write concise code exactly, but if you posted your code somewhere the odds were good that somebody would reply with a way to do the same thing with less code, followed by someone else who managed to shave several lines/characters off of that, etc.
While almost all of the time it was all just people having fun (perl is fun and play was encouraged) and not an admonishment of the code you'd posted or an example of how it should have been written I can see how some folks might have gotten that impression. Especially if they were new to perl and were more used to languages where TIMTOWTDI wasn't thing
There was 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.
> There was strong cultural pressure to be able to write perl in as few bytes as possible
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.
One-liners is one of the ways you can use perl. You can also use it as the embedded language in some larger project. As perl CGI. As mod_perl. etc. There is no "cultural pressure" to use any of these. You can choose to mess around with one-liners and you can choose to spend time shaving a few characters off your code. Or not. None of this is the one true way. This is not python.
I lived it. I'm sure there's still some Mailing List archives and IRC snippets that still endure, demonstrating the utter vicious 1-upmanship of how to do something in Perl as succinctly as possible. Why do X and Y when you can just do Z? What are you really trying to do? etc.
You COULD, if you wanted, and spent quite a bit of effort in the pursuit of that hobby, participate in one-liner, or obfuscation, or golfing friendly contests. Which were enabled by perl's expressiveness constructs. Nobody pushed anyone into that. On the contrary "there is more than one way to do it" was there to legitimize that getting the problem solved was the goal - instead of trying to force a one true way (like python).
After that, experts would often propose multiple ways to do something when they answered questions. THEY found that intellectually playful and exciting. They still do. And for the rest of us, that was an amazing way to learn more and understand more of that tool we were using daily. Still is.
You apparently saw viciousness in this and that certainly sucks.
Those experts were horrendously vicious. I can name them and can still describe their dismissive cruelty, since I spent ten years socializing nonstop in the Perl5 core communities (and have a CPAN id, and have an Authors entry in Perl5 core). Think “Linus before he learned to stop insulting people’s worth and focus on critiquing their work instead”. It was absolutely intended as a form of cultural propagation: I can do this more succinctly, so You Should Be Ashamed Before Me. If somehow you weren’t exposed to that aspect of it, I envy you.
Interestingly, that same prideful “my way is so obviously better that it’s a ridiculous waste of my time considering yours” ended up carrying forward to Mozilla, which was launched in part by cultural exports of the Perl5 conservative-libertarian community, and for a decade developer hiring was filtered for cultural sameness, leaving a forest of TMTOWTDI trees that viewed meadows as an aberration to be reforested back to their sameness.
You indeed ran into toxic environments. I don't feel that the common, new perl programmer intake path was anything like that. Not what I ever ran into.
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.
It was primarily the exhaustion of experts at tireless waves of newbies who hadn’t studied the available materials.
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.
Perl's "decline" saved it from a fate worst than death: popularity and splitting into dozens of incompatible versions from added/removed features (like python). Instead Perl is just available everywhere in the same stable form. Scripts always can just use the system perl interpreter. And most of the time a script written in $currentyear can run just as well on a perl system interpreter from 2 decades ago (and vice versa). It is the perfect language for system adminstration and personal use. Even if it isn't for machine learning and those kinds of bleeding edge things that need constant major changes. There are trade-offs.
This kind of ubiquitous availablility (from early popularity) combined with the huge drop-off in popularity due to raku/etc, lead to a unique and very valuable situation unmatched by any other comparable language. Perl just works everywhere. No containers, no dep hell, no specific versions of the language needed. Perl is Perl and it does what it always has reliably.
Perl's binary brings with it the ability to run every release of the language, from 5.8 onwards. You can mix and match Perl 5.30 code with 5.8 code with 5.20 code, whatever, just say "use v5.20.0;" at the start of each module or script.
By comparison, Python can barely go one version without both introducing new things and removing old things from the language, so anything written in Python is only safe for a a fragile, narrow window of versions, and anything written for it needs to keep being updated just to stay where it is.
Python interpreter: if you can tell "print" is being used as a keyword rather than a function call, in order to scold the programmer for doing that, you can equally just perform the function call.
> By comparison, Python can barely go one version without both introducing new things and removing old things from the language
Overwhelmingly, what gets removed is from the standard library, and it's extremely old stuff. As recently as 3.11 you could use `distutils` (the predecessor to Setuptools). And in 3.12 you could still use `pipes` (a predecessor to `subprocess` that nobody ever talked about even when `subprocess` was new; `subprocess` was viewed as directly replacing DIY with `os.system` and the `os.exec` family). And `sunau`. And `telnetlib`.
Can you show me a real-world package that was held back because the code needed a feature or semantics from the interpreter* of a 3.x Python version that was going EOL?
> Python interpreter: if you can tell "print" is being used as a keyword rather than a function call, in order to scold the programmer for doing that, you can equally just perform the function call.
No, that doesn't work because the statement form has radically different semantics. You'd need to keep the entire grammar for it (and decide what to do if someone tries to embed a "print statement" in a larger expression). Plus the function calls can usually be parsed as the statement form with entirely permissible parentheses, so you have to decide whether a file that uses the statement should switch everything over to the legacy parsing. Plus the function call affords syntax that doesn't work with the original statement form, so you have to decide whether to accept those as well, or else how to report the error. Plus in 2.7, surrounding parentheses are not redundant, and change the meaning:
$ py2.7
Python 2.7.18 (default, Feb 20 2025, 09:47:11)
[GCC 13.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print('foo', 'bar')
('foo', 'bar')
>>> print 'foo', 'bar'
foo bar
The incompatible bytes/string handling is also a fundamental shift. You would at least need a pragma.
> Can you show me a real-world package that was held back because the code needed a feature or semantics from the interpreter
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:
> Compared to Python's deliberate policy, which is they won't guarantee your code will still run after two minor releases
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.)
Well isn't that nice. The boxes I care most about are 32 bit. The perl I use is 5.0 circa 2008. May you amiga386, or anyone else, thank you in advance, may be able to tell me what do I need to upgrade to perl 5.8?
Is it only perl 5.8 and whatever is the contemporaneous gcc? Will the rest of
my Suse 11.1 circa 2008, crunch? May I have two gcc's on the same box/distro version,
and give the path to the later one when I need it? The reason I am still with
Suse 11.1, is later releases broke other earlier things I care about, and I could not fix.
What incompatible versions of pythons do you mean? I'm entirely unaware of any forks, and the youngest version I have to supply at the moment is 3.9, which is over 5 years old and available in all supported platforms.
Try to run any random python program of moderate dep use on your python 3.9 system interpreter without using containers. Most likely you'll have to use a venv or the like and setup a special version of python just for that application. It's the standard now because system Python can't do it. In practice, pragmatically, there is no Python. Only pythons. And that's not even getting in to the major breakages in point version upgrades or the whole python 2 to 3 language switch.
> Most likely you'll have to use a venv or the like and setup a special version of python just for that application.
Using venvs is trivial (and orders of magnitude more lightweight than a container). And virtually every popular package has a policy of supporting at least all currently supported Python versions with each new release.
You need to set up a venv because of how the language is designed, and how it has always worked since the beginning. Python doesn't accommodate multiple versions of a package in the same runtime environment, full stop. The syntax doesn't provide for version numbers on imports. Imports are cached by symbolic name and everyone is explicitly expected to rely on this for program correctness (i.e., your library can have global state and the client will get a singleton module object). People just didn't notice/care because the entire "ecosystem" concept didn't exist yet.
I have at least one local from-source build of every Python from 3.3-3.14 inclusive (plus 2.7); it's easy to do. But I have them explicitly for testing, not because using someone else's project forces me to. The ecosystem is just not like that unless perhaps you are specifically using some sort of PyTorch/CUDA/Tensorflow related stack.
> It's the standard now because system Python can't do it.
Your system Python absolutely can have packages installed into it. The restrictions are because your Linux distro wants to be able to manage the system environment. The system package manager shouldn't have to grok files that it didn't put there, and system tools shouldn't have to risk picking up a dependency you put there. Please read https://peps.python.org/pep-0668/, especially the motivation and rationale sections.
> major breakages in point version upgrades
I can think of exactly one (`async` becoming a keyword, breaking Tensorflow that was using it as a parameter name). And they responded to that by introducing the concept of soft keywords. Beyond that, it's just not a thing for your code to become syntactically invalid or to change in semantics because of a 3.x point version change. It's just the standard library that has changes or removals. You can trivially fix this by vendoring the old code.
> And that's not even getting in to the major breakages in point version upgrades or the whole python 2 to 3 language switch.
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
How old are you now? Mid fifties here. And 'vibe coding' in what exactly - it is not of interest from a programming perspective, but from a 'what does the AI know best perspective'? I've followed a similar, but not identical trajectory and now vibe in python/htmx/flask without needing to review the code in depth (NB internal apps, not public facing ones), with claude code max. Vibe coding in the last 6-8 weeks now also seems to make a decent fist of embedded coding - esp32/arduino/esp-32, also claude code.
35–44. Same thing, sometimes it makes planning errors, or misses context that should be obvious based on the files, but overall a huge booster. No need to review in depth, just set it against tests and let it iterate. So much potential, so exciting.
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.
I'm not sure about the Perl-specific claims here, but it is amusing how pervasive "on one or more occasions, I got a dopamine release after managing to struggle through the horror and misery of X: now I'm convinced that X is Good, Actually" seems to be in computing.
But is it all equally a struggle? Some things are definitely more of a struggle than others. Remember xfree86config? We used to have to manually configure our screen resolution in a shitty text file. I even remembered that you had to specifically add a line to tell it you had a 3 button mouse. This was in the late 90s, maybe early 00s. Way after it was sane to have to do that.
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.
I didn't have this experience when I first learned C#. Everything just kind of worked the way I expected it to. There are sharp edges, but far fewer than expected and always for an actual reason.
My first and only experience with Perl was like this: in 1997, just for fun, I tried to write a program in Perl to turn my Mozilla bookmarks into a website. After a week of not succeeding, in frustration I decided to try Python. In two days I had what I wanted, and programming it was a joy. That sealed my judgement that Perl (and all of its culture) was not for me, so I'm not surprised at all that others might feel the same.
(To be fair, there's a single oneliner that does make life a lot easier: ... | perl -pe 's{...}{...}')
I hope this doesn't come off as argumentative. You said that with Python "In two days I had what I wanted", but another way of looking at it: in a week of not succeeding in Perl plus those two days in Python, you had what you wanted.
I tried to learn perl a few times early in my career, we still had some old perl internal sites and a bit of tooling written in it. I really struggled to find good resources on the web at the time, and most of the perl I was exposed to was so badly written as to be incomprehensible to me. I knew C and Python at the time.
I wonder how common my experience was and why the next gen (at the time) I was part of never learned it
I had the exact same experience. The Perl I encountered early in my career seemed hard to understand in way other languages weren’t. I also didn’t feel I made progress quickly trying to learn it, every time I thought I had my feet under me I’d encounter a new sigil or a new pattern and be back to having no idea what the code was doing.
Spot on: the toxic culture around the language was a nail in its coffin.
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 cult of RTFM is so painful to interact with and off putting. The concept is sound, reading documentation is important. However simply responding to all questions with "RTFM" is not only not helpful but as often as not useless advice.
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.
> [TIMTOWTDI] literally means 'there is more than one way to do it in Perl' - and you can perhaps infer from that that there's little to no reason to do it using anything else
Not my experience at all, FWIW. For me, and the vast majority of Perl devs I’ve worked with over the past 30 years, TIMTOWTDI absolutely means some of the “ways to do it” don’t involve Perl, and that’s not only OK but expected. Of course Perl isn’t the be all/end all. It’s a lot of fun though!
(I’m a majority Perl coder to this day, it’s my favourite language by far. Hell, I even find it readable and easy/fun to debug)
It is possible to do so, but it stands out in a way such that most people aren't doing it using direct language features unless necessary. If you have `strict` and `warnings` enabled, which is recommended, then the interpreter can give runtime warnings or compile-time errors if you try to manipulate the symbol table or redefine a function. If you still want to use those on a case-by-case basis, you have to turn off those pragmas within a scope. So there are built-in ways the language discourages using them arbitrarily.
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 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.
Very. I use `Test::MockModule` (not just in tests) or `Sub::Override` or `Class::Method::Modifiers` a lot, according to convention/style or as I see appropriate — but there are, of course, tons more ways to do it.
Rather than its "decline was", Perl's existence is cultural. All programming languages (or any thought tools) are reflections and projections of the cognitive values of the community who creates and maintains them. In short, the Perl language shares the structure of the typical Perl dev's mind.
A shift to Python or Ruby is fundamentally a shift to a different set of core cognitive patterns. This influences how problems are solved and how sense is made of the world, with the programming languages being tools to facilitate and, more often than not, shepherd thought processes.
The culture shift we have seen with corporations and socialized practices for collaboration, coding conventions, and more coincides with the decline of a language that does in fact have a culture that demands you RTFM. Now, the dominant culture in tech is one that either centralizes solutions to extract and rent seek or that pretends that complexity and nuance does not exist so as to move as quickly as possible, externalizing the consequences until later.
If you've been on this forum for a while, what I am saying should seem familiar, because the foundations have already been laid out in "The Pervert's Guide to Computer Programming", which applies Lacanian psychoanalysis to cognitive patterns present in various languages[1][2]. This explains the so-called decline of Perl—many people still quietly use it in the background. It also explains the conflict between Rust and C culture.
As an aside, I created a tool that can use this analysis to help companies hire devs even if they use unorthodox languages like Zig or Nim. I also briefly explored exposing it as a SaaS to help HR make sense of this (since most HR generalists don't code and so have to go with their gut on interviews, which requires them to repeat what they have already seen). With that stated, I don't believe there is a large enough market for such a tool in this hiring economy. I could be wrong.
This is interesting to me, as someone moving from a company that uses C++ to one that uses Rust. It feels like the whole culture of the former company is built similarly - no guardrails, no required testing, or code review, minimal "red-tape".
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.
I think a big part is does someone starting to program even hear that Perl exists? No, and they start learning python and so have little need to learn Perl after that
That's why it has stayed dead. But that can't explain how it died. People don't just spontaneously stop hearing about the existence of a programming language in common use.
Which is (sadly) hilarious because that was the reason most people seem to have gone with python: they were told "this is what we use here" or they bought the "line noise" nonsense. They never put much effort into this.
But I also think that people who are truly interested in programming immediately learn that there are many different paradigms. And the net makes it dead easy for them to explore different directions and, I don't know, fall in love with haskell or something. Perl is plenty visible enough for THAT. I don't know about perl 6 / raku though.
I spent year developing CMS in Perl in 1999 (HTA application with ActivePerl. wonder if anybody else did something like this). It traumatized me, and first thing that I did in my next job is to learn python and develop some core systems in it. Few of my friends moved from perl to python as well.
I still remember spending time with my coworkers on bench outside of building trying to figure out #@$%$^&$%@something = []sd[dsd]@$#!&lala lines written by previous developers
Before I eventually switched to PHP, I ended up writing multiple CMS-like solutions that would run via `cgi-bin` but write contents to the webroot (what we would now call a static site generator). As I was quite limited with the standard shared hosting at the time, I ended up inventing my own single file database format (it was a simple text file) to keep state. It worked quite beautifully and kept me afloat for the first few years of my life as a web developer around the early 2000s.
I was aware of ActivePerl and quite liked Komodo. Thankfully I could keep myself from doing things on Windows/IIS apart from a brief stint writing a single file CMS in ASP.
I wrote php2 + msql before starting in that company (and a bit of php3). Like in your case it was essentially static site generator but the management part was HTA (application hosted in internet explorer. you could write one using whatever activex/language: vbscript, python, perl).
as backend we had oracle. at first we tried oracle/linux (just released). but we never managed make it work (oracle engineers that came to us failed as well). So we got dedicated sun server for it.
One day I was bored, installed mysql on my workstation, made a changes in couple of queries and all of sudden i got x20 performance of sun box with oracle. Lead developer said that it's bad solution as mysql doesn't properly supports referential integrity (we didn't actually used it in oracle iirc)
Yesterday I used `pwgen` to role a random password, and at first glance I legit thought it might've been working Perl code. I'm not even slightly kidding.
Perl heads are downvoting you but I agree as a longtime ex Perl user that the sigils were noisy nonsense.
The original intent was you could see var types with them - $scalar, @array, %hash.
They immediately broke this by deciding the sigil would apply to the value /extracted/ from the data structure. So you declared array @foo but accessed an element as $foo[1]. What? There’s a logic there but already you’re violating many people’s expectations so why even have them. The sigils are now confusing many people instead of clarifying anything.
The sigil idea then /completely/ failed when they introduced references and “complex data structures” (nesting arrays within arrays like every other language - in Perl this was a special thing because they had been flattening lists by default so no way to put one inside another).
So now to get at a hash in a hash you used not % but $ since a reference is a scalar. $hash1->$hash2->{“key”}. Versus $hash3{“key”} for a simple hash. Just awful noisy syntax. Due to poor language design up front.
Oops last example should be $hash1->{“hash2”} - this is a whole hash referenced with $ because of the implementation detail that it is in hash1 as a reference, which is considered a scalar.
Technically you are allowed to use % like so: %{$hash1->{“hash2”}}. Which, just - lol.
That last paragraph got me off Perl to Python. The first time I wrote Python like hash1[hash2]["key"] and it worked, then tried hash1[hash2]["array_name"][3] and it worked because that's the obvious way to write something, I fell in love and never looked back.
I never wanted to have to reason my way through chasing pointers through nested hashrefs again.
Before that job in perl i wrote asm/tcl/delphi/c/php (and bunch of other languages after).
This perl syntax caused some kind of rejection on almost physical level. It was same for many of my friends. "Zen of python" was a breath of fresh air.
The lede says Perl died because it was "reactionary" and "culturally conservative", but the content says Perl died because it had bad culture, the culture of angry, socially corrosive anonymous internet commenters.
If Perl had had a good culture, then conserving it would have been good!
That was effectively the culture of the Internet in general at that time. It was the "wild west" for years, because, well, it _was_ a modern incarnation of the same phenomenon.
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.
Surely the people who had purely performance problems with Perl CGI scripts moved to mod_perl? I didn't figure out when mod_php was introduced from casual searching, but given that mod_perl is only a year younger than PHP it must've been available to almost anyone who was considering rewriting their app in PHP. So I have to imagine there were additional reasons.
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.
mod_php was distributed w/ Apache httpd, so it was "already installed". mod_perl needed to be installed manually, so it posed immediate friction, if not a complete freeze-out, depending on the situ. I believe that was why PHP became popular.
Systems with mod_perl (or just Perl allowing normal CGI) installed, especially shared hosting was so common as to be the norm in the late 90s and early 00s.
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".
Perl CGI scripts were ubiquitously supported by shared hosts, but IIRC mod_perl was not unless you had some custom setup on a dedicated server. Also IIRC, mod_perl was just a lot more complicated to set up and use, while mod_php was dead simple.
I'd take this a step further and say that the design flaws that motivated Perl6 were what really killed Perl. Perl6 just accelerated the timeline.
I do imagine a saner migration could've been done - for example, declaring that regexes must not start with a non-escaped space and division must be surrounded by space, to fix one of the parsing problems - with the usual `use` incremental migration.
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.
Excellent point in the last paragraph. Python, JavaScript, Rust, Swift, and C# all have/had business models and business advocates in a way that Perl never did.
Do you not think O'Reilly Associates fits some of that role? It seemed like Perl had more commercial backing compared to the other scripting languages if anything at that point. Python and JavaScript were picked up by Google, but later. Amazon was originally built out of Perl. Perl never converted its industry footprint into that kind of advocacy, I think some of that is also culture-driven.
Maybe until the 2001 O'Reilly layoffs. Tim hired Larry for about 5 years, but that was mostly working on the third edition of the Camel. A handful of other Perl luminaries worked there at the same time (Jon Orwant, Nat Torkington).
When I joined in 2002, there were only a couple of developers in general, and no one sponsored to work on or evangelize any specific technology full time. Sometimes I wonder if Sun had more paid people working on Tcl.
I don't mean to malign or sideline the work anyone at ORA or ActiveState did in those days. Certainly the latter did more work to make Perl a first-class language on Windows than anyone. Yet that's very different from a funded Python Software Foundation or Sun supporting Java or the entire web browser industry funding JavaScript or....
Thanks for detailed reply. Yes, the marketing budget for Java was unmatched, but to my eye they were in retreat towards the Enterprise datacentre by 2001. I don't think the Python foundation had launched until 2001. Amazon was migrating off Perl and Oracle. JavaScript only got interesting after Google maps/Wave I think, arguably the second browser wars start when Apple launches Safari, late 2002.
So, I guess the counterfactual line of enquiry ought to be why Perl didn't, or couldn't, or didn't want, to pivot towards stronger commercial backing, sooner.
People were being crybabies; the critics were extremely vocal and few. Python 3 improved the language in every way and the tooling to upgrade remains unmatched.
It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode.
Organizations struggled with it but they struggle with basically every breaking change. I was on the tooling team that helped an organization handle the transition of about 5 million lines of data science code from python 2.7 to 3.2. We also had to handle other breaking changes like airflow upgrades, spark 2->3, intel->amd->graviton.
At that scale all those changes are a big deal. Heck even the pickle protocol change in Python 3.8 was a big deal for us. I wouldn't characterize the python 2->3 transition as a significantly bigger deal than some of the others. In many ways it was easier because so much hay was made about it there was a lot of knowledge and tooling.
> It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode.
They should've just used Python 2's strings as UTF-8. No need to break every existing program, just deprecate and discourage the old Python Unicode type. The new Unicode type (Python 3's string) is a complicated mess, and anyone who thinks it is simple and clean isn't aware of what's going on under the hood.
Having your strings be a simple array of bytes, which might be UTF-8 or WTF-8, seems to be working out pretty well for Go.
What you propose would have, among other things, broken the well established expectation of random access for strings, including for slicing, while leaving behind unclear semantics about what encoding was used. (If you read in data in a different encoding and aren't forced to do something about it before passing it to a system that expects UTF-8, that's a recipe for disaster.) It would also leave unclear semantics for cases where the underlying bytes aren't valid UTF-8 data (do you just fail on every operation? Fail on the ones that happen to encounter the invalid bytes?), which in turn is also problematic for command-line arguments.
With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade.
Imagine if the same interpreter supported both Python 3 and Python 2. Python 3 code could import a Python 2 module, or vice versa. Codebases could migrate somewhat more incrementally. Python 2 code's idea of a "string" would be bytes, and python 3's idea of a "string" would be unicode, but both can speak the other's language, they just have different names for things, so you can migrate.
That split between bytes and unicode made better code. Bytes are what you get from the network. Is it a PNG? A paragraph of text? Who knows! But in Python 2, you treated them both as the same thing: a series of bytes.
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.
That distinction is indeed critical, and I'm not suggesting removing that distinction. My point is that you could give all those types names, and manage the transition by having Python 3 change the defaults (e.g. that a string is unicode).
I’m a little confused. That’s basically with Python 3 did, right? In py2, “foo” is a string of bytes, and u”foo” is Unicode. In py3, both are Unicode, and bytes() is a string of bytes.
The difference is that the two don't interoperate. You can't import a Python 3 module from Python 2 or vice versa; you have to use completely separate interpreters to run them.
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.
Why would I ever risk inflicting a stack trace like
Traceback (most recent call last):
File "x.py", line 2, in <module>
foo.encode()
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128)
on a user of Python 3.x where it isn't possible? (Note the UnicodeDecodeError coming from an attempt to encode.)
It would absolutely have been harder. But the pain of going that path might potentially have been less than the pain of the Python 2 to Python 3 transition. Or, possibly, it wouldn't have been; I'm not claiming the tradeoff is obvious even in hindsight here.
I think you have causation reversed: it would have been at least two orders of magnitude greater to act like moving to python 3 was harder than staying. But you do you boo :emoji-kissey-face:
Pain on whose part? There was certainly pain porting all the code that had to be ported to Python 3 so that the Python developers could have an easier time.
My problem with PERL was always that there's just too many things to remember, particularly if the code I'm debugging was written by someone who knows the language well. I'd be on a PERL project for awhile, then get pulled off to do Java or Ruby or whatever. By the time I needed to do PERL again, I had to go back and relearn everything. I never had that problem with Java, Ruby, Python, or Javascript.
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.
I don't know, but for me Perl has not died at all. I still use it for smallish scripts and some CGI. Maybe I am an old retired fart, but it is the tool I reach for, when the problem looks like Perl-ish. Like I reach for C or other languages when I need that kind of things.
agreed. it's often in my toolbox -- mostly since I already know it, and I prefer semi-colon-driven syntax -- but it's just one of a few languages I use.
By a lot of metrics it was a pretty awful language; hard to read, implicit, inconsistent, uncomfortable to write due to all the special characters etc. The idea of default arguments alone should have killed it by being a monumentally bad idea.
In my recollection perl6 helped kill it by making perl5 stagnate, but hopefully it would have died regardless.
I remember the first time a saw Perl, it looked like some kind of alien language from outer space, all the symbols it used looked insane.
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.
> I wrote a lot of Perl in the mid 90s and subsequently worked on some of the most trafficked sites on the web in mod_perl in the early 2000s, so I have some thoughts.
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.
Perl being so old means it's extremely fast for what it's designed to do, process streams or pipes. In a few tasks, it's faster than C, but being much faster to create a script or program that is useful, and with the implicit syntactic sugar, and since it's so flexible, you can just do things in the one way you know how and that's usually good enough.
Python is pretty good too for this and because modern computers are so fast it doesn't matter that it's much slower than perl, but if you're doing something like processing terabytes of files, it's probably worth your time to find or vibe code a one-liner in perl and torture it into working for your task.
Perl is amazing when it comes to regular expressions too. It's one of the reasons why perl is way more fun to write than Python. I still use perl for regex heavy tasks. I wish that python had integrated regex into the language the same way.
Perl's decline was cultural in the same way VMS's decline was. A fantastic approach and ecosystem—just one overtaken by a world that was moving on to a different set of desires and values.
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.
VMS decline was bound to a failing hardware business and company. That's a very different thing. Unix was around in the 80s and VMS did fine, its when DEC hardware business went down the tubes VMS lost out big time.
I think PHP is way more accessible syntactically, even with all the standard complaints about the language. In the early 2000s it felt like "simple C style function calls embedded in HTML templates" more or less. Not much to have to teach there.
And serving it tends to be "copy the files to your web server's public dir".
mod_php was dramatically simpler to use than mod_perl. If the sysadmin set it up, you didn't need to know it was there, and your regular PHP just ran really fast. That and nothing else really copied the "scriptable HTML file" paradigm which some people really really liked and made a very low barrier to entry compared to Perl. That's really what kicked off the demise of Perl -- it stopped being the most accessible way onto the internet. PHP also didn't screw up their major language upgrades like Perl did.
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.
Perl is a very difficult language. PHP was a comparatively simple language. PHP was just a scripting language for C and incorporated as many open source C libraries as possible back when open source libraries were a bit of disjointed mess.
PHP's success and Perl's decline was obvious at the time.
PHP has fallen off. Who is doing anything new in PHP?
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.
As someone who doesn't really know neither Perl nor PHP, PHP is more of a domain-specific EDSL than a mainstream programming language.
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.
Perl died for many reasons. For me, it was a language that was always too tempting to be too clever by half. I'd been using Perl pretty significantly from 1995-2000 (perl4 to perl5) when I was introduced to Python (1.5.2)[^1]. I greatly appreciated its simplicity, zen, batteries included standard lib, and REPL. I found add on packages easier to install than dealing with CPAN. I switched to Python and basically never looked back.
I had an interesting experience starting a job at ZipRecruiter, and finding that up to that point (2022), most of their code had been written in Perl. Their CTO had just gotten fed up with Perl and decreed that from now on, all new projects should be written in Go. I was the first one on my team to write code in Go.
There were various greybeards who kept telling me that Perl was a perfectly fine language and was fast enough for most purposes. I didn't argue with them and just backed away slowly.
Regarding Perl as a language, it seemed fine in the 1990s as a slightly more advanced alternative to Unix shells. But for me, what made it a failure as a language is that in order to have an array of hashes, or a hash of arrays, you needed to use references. That may have been a nice hack to enable some things in the 1990s, but even in 2005 that sounds pretty primitive and outdated to me. Plus the reliance on using magical variables consisting of $ and every non-letter ASCII character for all kinds of random stuff, like $_ and $# and so on. That may have been cool in 1992, but it's not 1992 any more.
Overall, Perl was pretty neat for little scripts up to 20 lines, but a bad idea for building an entire company on (like ZipRecruiter.) That's more of an indictment of ZipRecruiter than Perl.
Perl was super for little scripts hence it became popular. I think the killer feature was its fantastic regular expression language which beat everything at the time. All other languages had to do to was neutralise that one advantage and they did.
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.
25 years ago Perl allowed you to express what was in your head 10x more concisely as in other mainstream language (which have since caught up with some of the features).
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 thought it was really perceptive. Look at what JS was designed to do cf. what it's actually doing these days.
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.
I have experienced the decline in interest in Perl firsthand - having teached a class in Practical Perl Programming for 10 years at a local major university. First years saw 270ppl, second 150, then 100, 80, 50, and I think the last issue was 12 people.
I can speculate a lot about what killed Perl, or at least what called the schism, and in general what was the cause of the schism had roots in what Perl failed to innovate on. The cultural stuff was a side-effect of it.
But then also - Perl has huuuge impact on so many other languages, including JavaScript, that its place in the hall of fame cannot ever be disputed.
Should the Rust community take a lesson here, and maybe the Zig community to an extent?
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.
Agreed. The Rust community is an incredibly toxic place because they are so determined to involve politics in tech. I love the language, but I stay as far away from the community as I possibly can.
I'd love for politics to not infiltrate most aspects of life. Until everyone is able to, at least in part, persue life without being oppressed because of their immutable attributes, their belief or lack of belief system, who they choose to love and/or how they view themselves I think it's our civic duty to crusade for those causes.
> I think it's our civic duty to crusade for those causes
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?
There is zero way you don't alienate anyone. Ask women software engineers if they ever feel alienated. That's the reason why some communities like the python community do outreach for minorities in tech.
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.
> 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.
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.
> There's ALWAYS another place you can do something. Always. Where you draw the line is arbitrary.
Yes, that's the point. If you're drawing a line that agentively impacts others, you are the one responsible for defending where it's drawn.
> There's no rulebook anywhere saying we can't do this in tech.
Nobody is telling you that you can't do these things (except where impermissible by law). They are telling you not to rope or pressure unwilling others into it.
I think where we disagree is the "roping people in" thing.
If you're part of an organization, you're gonna be roped into their organization standards. Whether that be for behavior (no cursing on their forums), or for outreach, or whatever.
Joining the organization is optional, and if you feel, say, the python foundation doesn't align with your own beliefs, then just don't join. That's always been allowed.
As for working with people you might not want to, that's also just a part of organizations.
> Ask women software engineers if they ever feel alienated.
I have, on multiple occasions. The general summary of what I have learned from doing so, is that they find it cringe to ask, and appear annoyed by the suspicion that they're getting roped into someone else's political battle.
> That's the reason why some communities like the python community do outreach for minorities in tech.
No, they do it because it aligns with the cultural values of the people in charge. (As it happens, it also aligned with GvR's values when he was in charge.)
> I'm a white man, and I have never felt "alienated" in so-called progressive spaces.
... You don't feel alienated when people in your vicinity openly use pejorative language to refer to groups that you belong to (and don't have a choice about), or decry politicians or even pundits that dare to validate your grievances as extremists? You don't feel alienated when it's proposed that your grievances are inherently invalid because of that group belonging? You don't feel alienated by being repeatedly told that said group belonging makes you inherently incapable of "empathy" for various others, even as that same "empathy" is demanded of you? You don't feel alienated by the cultural assumption that a desire for more progressive income taxation, or cleaner energy, dictates a raft of social policies? You don't feel alienated by the entire body of in-group jargon that associates your group membership with negative qualities, or the opposition to language unilaterally deemed to reflect your "privilege" regardless of actual etymology?
If you haven't experienced these things, please let me know where to find the "progressive spaces" you frequent. I don't think I've seen one since at least OWS.
Way back, Perl got off the ground really because, in contrast to the C compilers of the era, code written on one Unix ran on the others, usually unmodified. In my first jobs, where we had heterogeneous mixes of commercial Unixes, this was unbeatable. It also wrote like higher level shell, which made it easy to learn for systems people, who really were the only ones that cared about running things on multiple platforms most of the time anyway.
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.
Nobody will agree with this hot take, but I was around in the perl years, so maybe take this opinion with a grain of salt:
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.
There were programming envs that were easy to pick up in contemporary times. Hypercard is one that's often especially-fondly referenced as a non-traditional-programmer friendly example. Basic was much less arcane syntax-wise too. It's been a LONG time since I used Pascal but I also remember it being simpler to pick up.
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.
My client uses IBM servers with it’s hobbled version of Unix (AIX). Perl and access to copilot have really helped me out. I don’t love Perl but I’m damn glad I have acres to it.
This theory may only sound convincing if you ignore parts of history which don't fit. Which is pretty much all of them. RTFM-culture was the norm for all online computer-related communities until 00s. Nothing of this phenomenon is Perl-specific.
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 Perl programmers as being weird but nice enough. It's Lisp programmers who were impossible to talk to and mostly responded to any questions by telling you to kill yourself.
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.
No mention of taint mode, you had to untaint all data coming from user. By comparing to fixed string or convert to number or filter through regexp at least. If this were more broadly adopted, would save everyone so many headaches.
Psst: even if you aren't using uv, you can use a global pip with `--python` and create your venvs `--without-pip` to save time (unless you have many invocations per venv, since `--python` works through a not-very-sane hack and is a bit slower as a result). And you can use Pipx to provision that global pip, and then you also have Pipx available. https://zahlman.github.io/posts/2025/01/07/python-packaging-...
There is no doubt that a product’s community culture and the maintainer’s attitude have a significant influence.
However, I used Perl and stopped using it without knowing anything about its internal politics or community. PHP, ASP, Java JSP and later Rails were much better than Perl for web development.
* I know that for some the mention of JSP will be rare, as it was ugly… However in the 2000s it was the state of the art
I never really warmed to perl in its era but perl dbi was kind of perfect in its way. If you needed what it could do, it got very intuitive very fast, and was pretty terse. Both of which were supposedly the appeal of perl.
Neither is Ruby that has also similarly disappeared and article praised it? Or Lisp? On the opposite end, C, PHP, JS that are omni-present are good languages? Sometimes meritocracy and success don't align.
Ironically alluding to the possibility of others who would castigate you for saying something reasonable things, is not any less obnoxious than the castigation.
Perl 5's non-breaking conservatism kept old scripts running forever, but it also meant there was never a clear migration path the way Python 3 eventually provided, and that made long term planning a lot harder.
Though at the same time the bit where `use strict` was optional wound up being off-putting to a lot of us, at least in part because we'd always wind up with _something_ that wasn't designed for `use strict` and had, uh, interesting failure modes.
It's the same drive that we see from JS to TS these days, or adding type hints to Python, and even to some extent why people pick up Rust: because you get a refusal to act and an explanation rather than wonky results when you goof.
IME there's been a wider shift away from worse-is-better, and Perl was kind of one of the early casualties of that. Part of that is also how science has marched on: When Python and Perl were new, the most popular typed languages were kind of tedious but not what people would consider _good_ at types these days. Perl was the first language I learned, and if I was transported back to the 1990s, I'd probably still pick it, even if I don't use it in 2025.
(OK, maybe I'd go all in on OCaml. Any way the camel wins.)
Perl's "decline" means there is some metric to measure how high Perl is. It was higher, but now it is lower. I don't think the metric is well-defined, though.
Perl shaped so much of early web culture. It’s interesting how a language can fade not because of capability, but because the community’s momentum shifted elsewhere.
I didn't like cpan and python was just easier and available, if python didn't exist I'd like to think I'd have invested heavily in perl because it was everywhere at some point.
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).
Well that's not what I meant. Does everything has to have taking over the world as a goal? Perl still exists, I guess it's updated, why isn't that enough?
> Does everything has to have taking over the world as a goal? Perl still exists, I guess it's updated, why isn't that enough?
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.
Yes: in retrospect, the Perl community (and maybe even the language in general) was cringe-worthy and perhaps even toxic.
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.
> Perl always had a significant amount of what you might call "BOFH" culture, which came from its old UNIX sysadmin roots. All of those passive aggressive idioms and in jokes like "RTFM", "lusers", "wizards", "asking for help the wrong way" etc.
> [...]
> Cultural conservatism as a first principle.
Counterpoint to this: Rust. Rust has a similar RTFM/"wizards" culture, but is not culturally conservative (in any sense of the word).
My two cents: Perl's "culture" had little to do with its fall. I think Perl's problems run much deeper. Perl is built on rotten foundations. It's fundamentally a scripting language (albeit with bolted on additions to make it kinda-OOP), and it therefore has all the problems that scripting languages have for building large software projects.
Those problems have no quick fix, and indeed fixing them would require throwing the language out entirely -- at which point, why not simply switch to another language entirely (which is exactly what happened...).
Probably stretching the cultural metaphor too far here, but Rust has much more of a “vanguard of the proletariat” vibe & appears susceptible to some of the problems inherent in that political mission.
I looked at Perl once and decided to just not use it, and hoped it'd go away so I never have to use it. Sorry, the decline was probably due to it being bad.
Perl was aimed at intelligent people that considered obfuscated code challenges a sport and had a tendency for masochism.
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.
Perl was a bad language, line noise. It was better than using bash and awk for complex scripting, and better than using C for CGI pages. But Python and PHP were better and more readable for those use cases, and killed Perl.
"Willing" is an interesting word choice. There was quite a bit of resistance in the Python world despite the clear benefits. (2.x really could not be fixed, because the semantics were fundamentally broken in many places.)
I worked for a few years in an large org which utilized perl for build scripts, testing automation, and a few other things. I would summarize the half decade Perl learning curve as initial bewilderment, intermediate cult like praise, to advance level disillusionment.
There was something about scaling usage in large teams that felt awkward and high friction.
I dunno, I interacted with perl about 2000-2003 in a small way, it always seemed pretty friendly and welcoming, I loved perlmonks and remember it happily.
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.
C'mon. The language was like something born in Hogwart's. Magic spells, incantations. It lost because it was not an easy language to learn - and others were (in particular Python) - while being just as powerful.
Perl failed because it's a write-only language. The only time you really understand a Perl program is when you're writing it. Check back in six months and good luck. It's like trying to read someone else's regular expression - and the connection between Perl and Regular Expressions is not accidental.
I don't get why Ruby is mentioned before PHP. The only Ruby thing I've ever come across is GitLab, and not with positive associations either - up until maybe 3, 4 years ago particularly Sidekiq was a constant point of utter pain.
I was surprised by that, too, and assumed it was a decade-old article until I saw the date at the bottom. Both being mentioned before Python is wilder, as is the total exclusion of JavaScript.
JavaScript on the backend is a rare thing to see, even in "resume driven development" scenarios it's usually some sort of static build that gets pushed to S3 or whatever.
Node.js is the most popular web framework/technology in the StackOverflow developer survey. Express is more popular than FastAPI, Django, Flask and Rails in the same survey. Just... what are you talking about?
i disagree, python is Just Better. ive never used perl but ive had to install it due to some antique tools requiring it, and every time its been an incomprehensible mess. i still have no idea how packages work in perl. also, it seems like everything in perl is a string? and the syntax looks like a mess.
maybe its painful for guys to admit that languages could be a lot better designed, and when such langauges appeared, everyone flocked to them.
The number of blogs posted on here by people who can’t be arsed to make their writing legible on mobile blows my mind. Did everybody just skip the section of their CSS journey that covered media queries or what?
I enjoyed the article but it was a nightmare to read on my phone’s browser
(Author) Sorry you had a poor experience, yes my blog "engine" is a hacked together POS that barely works, with hand written CSS, that was mostly built before the mobile first era, I have just tweaked it to work somewhat on portrait phone screens, but it's really not a very good website. I do try to generate fairly plain semantic HTML so the pages should work pretty well with "reader mode" or user stylesheets if you have access to that. That's probably the optimal experience.
I always found the Perl "community" to be really off-putting with all the monk and wizard nonsense. Then there was the whole one-liner thing that was all about being clever and obscure. Everything about Python came off as being much more serious and normal for a young nerd who wasn't a theater kid.
I'm having to pick up some perl now, and while I don't interact with the community, it surely _feels_ like it was written by wizards, for wizards. Obscure, non-intuitive oneliners, syntax that feels like it was intentionally written to be complicated, and a few other things that feel impossible to understand without reading the docs. (Before everyone jumps on me - yes, as a developer, I should be able to read documentation. And I did. But until I did so, what the code was doing was completely opaque to me. That feels like bad language design.)
Some of it I recognize as being an artefact of the time, when conciseness really mattered. But it's still obnoxious in 2025.
The whole thing reminds me of D&D, which is full of classes & spells that only exist in modern D&D because of One Guy who happened to be at the table with Gygax, who really wanted to be a wuxia guy he saw in a movie, or because he really wanted a spell to be applicable for that one night at the table, and now it's hard-coded into the game.
It’s interesting to me how brains work.
Perl has always “flowed” for me and made mostly intuitive sense. Every other language I’ve had to hack on to get something done is a struggle for me to fit into some rigid-feeling mental box.
I understand I’m the weird one, but man I miss Perl being an acceptable language to pound out a quick program in between “bash script” and “real developer”.
I think if you were a sysadmin and used to shell scripts, sed, awk, grep and xargs then perl probably made more sense than if you were a programmer from a more traditional language coming into the perl world.
As somone that switches between both roles, when doing DevOps (aka sysadmin in 21st century) even though there is more stress regarding dealing with infrastructure, there is a certain peace of mind being away from Scrum, Jira, milestones, and other stuff, versus plain shell scripts, sed, awk, grep and xargs, VMs up and down.
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.
As another “devops-y” guy (I’m essentially a sysadmin, but i accept whatever job title is trending right now) i agree on everything. It’s nice to see (from a distance) all the bs developers have to endure on a daily basis knowing it doesn’t affect me much.
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.
>I think if you were a sysadmin and used to shell scripts, sed, awk, grep and xargs then perl probably made more sense than if you were a programmer from a more traditional language coming into the perl world.
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.
That makes a lot of sense. After 30+ years of programming, I still have to do a search (or use an LLM) to do anything useful with sed, xargs, etc. Perl never really clicked with me either.
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.
If I am familiar with sed, awk, grep and xargs, was I a sysadmin ?
If you are familiar with all of these but not C or Java or some other "traditional" programming language, then yes, I think anyone would guess you were a sysadmin. This was the type of background GP was talking about - people familiar with shell scripting but not any other programming language, who come by Perl for the first time.
It's been a while, but I found for me personally, that Perl flows while writing it, but stops flowing when reading the same code after some time has passed. It was good for getting things done once, but no fun to maintain and adapt - at least the way I was using it decades ago. I moved from Perl to Python and never looked back.
LUKE: Is Perl better than Python?
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.
https://wiki.python.org/moin/PythonCdFun
If you’re in the market for fun hackable tool that sits between “bash script” and “real developer” I highly recommend checking out babashka.
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!
You might also enjoy Janet https://janet-lang.org/
Wow that IS cool!! Almost sounds too good to be true lol. Green threads? Repl? Event loop? One <1MB binary? What the heck!!
a different approach is to replace bash altogether and switch to modern shells like fish, elvish, murex, nushell (not stable yet afaik) or oils (very interesting approach, it has a bash or sh compatible mode and another one with a more modern and cleaner syntax).
[dead]
I agree. Perl made sense as a “step up” in the world of *sh and awk.
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.
Was Perl one of your first languages by any chance? I freely admit that I've only been poking at it for a few months; maybe by this time next year, I'll be boggled at the comment I left, like it was written by a different person.
> in between “bash script” and “real developer”.
One of my coworkers gave me some great perspective by saying, "at least it's not written in Bash!"
Yep, first language I learned. And since I was somewhat early to the Internet thing, I found IRC when I was about 14 years old and actually learned from a lot of the folks who have authored books on Perl or are at least (were) well known in the community.
It certainly was the major factor in how I connected the dots!
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.
Not the person you replied to, but I thought the same thing. Perl was my first as well, and it certainly shaped the way I think about coding. It made Python feel too rigid and Ruby feel familiar. There's something to be said for the restrictions of an environment when you're learning how to operate in a domain that seems to shape future thinking.
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.
> There's something to be said for the restrictions of an environment when you're learning how to operate in a domain that seems to shape future thinking.
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.
Seems somewhat related to Iverson's 1979 Turing Award lecture, "Notation as a Tool of Thought" (https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.p...)(https://news.ycombinator.com/item?id=25249563)
Reading the YCombinator link there's a mention of APL and a comment by dTal[1] which includes saying:
> "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:
and whoops that doesn't work; this notation brings to the focus that sum has to start with 0 and product has to start with 1 to get the right answer and you can wonder mathematically why that is; APL notation hides that just like it hides the looping. Different notation is a tool for changing the what people think about - what things we must attend to, cannot attend to, and what new things a notation enables us to see. dTal's next reply:> "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]:
In C# that task is str.TrimStart() and I assume it's a loop from the start of the string counting the spaces then stopping. Calculating length - num_of_spaces, allocating that much memory for the new string, copying the rest of the string into the new memory. I wouldn't think it was do-able using the same higher order function (\ scan) from a running sum. What this is doing to achieve the answer is different: Now how do I remove the leading 0s from a numeric array? In C# I can't reach for TrimStart() because it's a string only method. I also can't assume that there's a named method for every task I might possibly want to do. So I have to come up with something, and I have no hints how to do that. So I have to memorise the TrimStart() name on top of separately learning how TrimStart() works. That notation gives me a clear readable name that isn't transferable to anything else. In APL it's: That's the same pattern. Not clear and readable, but is transferable to other similar problems - and reveals that they can be considered similar problems. In C where strings are arrays of characters, you aren't doing whole array transforms. In C# strings are opaque. In APL strings are character arrays and you can do the same transforms as with numeric arrays.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.
[1] https://news.ycombinator.com/item?id=25258819
[2] https://aplcart.info/
this is why i like how operators work in pike:
+ - * / 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 only recently learned about this, maybe a month ago. It made a lot of sense to me.
> It made Python feel too rigid and Ruby feel familiar.
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.
> One of my coworkers gave me some great perspective by saying, "at least it's not written in Bash!"
I wish bash was the thing that was dying. As an industry, we need to make better choices.
i think this is changing. in recent years, alternative shells that break with bash syntax like fish or elvish and others are gaining in popularity. oils is of particular interest because it has an sh/bash compatible mode and thus provides an upgrade path away from bash.
Indeed. If I had to download and install bash … I wouldn’t!
I write bash scripts only because I can rely on it being there.
There’s nothing that can replace bash for what it does. People have been trying for decades. You’ll be happier if you accept that bash can and will happily coexist with anything and everything else, which is exactly why it will never go away.
>it will never go away
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.
CLI usage revolves around text and bash is a meta layer above that. Given curl, jq, and awk, you can create a quick MVP client for almost any api. Doing the same in Python and Go is much more involved.
Throw in nc and a while loop, and you can have a server too!
At least you have bash scripts. Most of my coworkers write tcsh scripts :|
(And yes, I have been pushing for bash or posix sh).
I wrote a ton of Perl 5 and also found it very intuitive and powerful. I think the notion that Python is "more readable" is true, but also less useful of a metric than it would seem. Python is still gibberish to a new coder and requires training and experience to master. Perl requires somewhat more effort to acclimate to, but ultimately is much more expressive and much closer to real-world software engineering problems. Once the incremental effort is made, Perl is (or at least was) a better Python.
For me it's not so much that Python was more "readable" than Perl. I've found pretty much any language other than XSLT more readable than Perl.
> Some of it I recognize as being an artefact of the time, when conciseness really mattered
It was an artefact of bursting out of those constraints, but honoring them still. The roots of perl as a “more capable, less restrictive” sed/awk means that it must support `perl -pi.bak -e oneliner file`, just like sed did — and so from that core requirement forward, everything it did, does. By the heyday of Perl5 era, conciseness was not a requirement, but the sed-compat roots remained a focus of the language’s creator.
It isn't bad language design that you need to study the language before you can use it. I look at haskell programs and it looks mysterious to me because I haven't spent any time studying it, but I'd not thing to say it is bad language design.
Yes, one can write obscure perl code and some love perl golfing. In the same way there is an IOCCC which delights in unreadable code, it doesn't mean that the C language should be relegated to the dustbin. The answer is to write readable code, no matter which language is in use.
But I can look at most Python code and be able to understand what it does. With perl, I have to look up so much.
- Why is there a `1;` on a single line in the middle of this file?
- What is `$_`?
- This parallel execution manager doesn't actually seem to define what code needs to run in parallel in any specific way, how does this work?
- What is this BEGIN block at the start of this Perl file? Why is that necessary?
- What's going on with qx, qw, qq?
- What does chomp do when it's just on its own line, with no arguments given to it?
To be able to fully comprehend Perl (even without having to embrace it), one needs a fiddle.
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.
$_ follows the spirit of shell variables (such as $*, $@, $! etc., heavily used in Korn, Bourne flavours but not the C flavours), but was repurposed or – more likely – picked from a pool of vacant characters with the help of a dice roll. Kind of like how ancient Egyptians built the pyramids with the help of sophisticated cranes and machinery and then vapourised their tools with high-particle beams to leave future generations guessing «how on Earth did they manage to do that». This is one of the main criticisms of Perl. Perl started out as an improvement over «awk», and BEGIN is an awk construct where it is used frequently, e.g. awk 'BEGIN { IFS=":" } { … do something … }' It follows the standard convention of UNIX utilities that expect the input to come from the standard input stream (file descriptor 0 or <file-in in the shell) when no input file name has been specified. So, when no <FILE1> given to chomp, it chomps on the standard input.Again: python syntax is more akin to what you are used to, and so it feels more comfortable to you.
$_ is inscrutable if you haven't studied perl, but the same thing would happen to anyone who sees a python decorator for the first time. what does "else: do after a while loop in python? Only people who know python know what it does (and I suspect most don't). The different quoting operators are also trivial to learn. In comparison, yield from python is also simple syntax but the semantics are much more involved.
BEGIN? Take 60 seconds to read what it means. And if you knew awk, you'd not have to do that, as it was directly lifted from awk.
> BEGIN? Take 60 seconds to read what it means.
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.
> 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).
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:
and these are also equivalent:It could've easily been defined that the else branch runs if the while condition never had a true value at all. In fact, I think that's more intuitive.
What are you trying to say? It is defined that way. And the example I provided above makes that completely explicit.
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-...
It's not just a matter of "read the docs", though, because languages can differ in how many distinct concepts/constructs they employ. Python has gradually added more over the years but still I think is well short of Perl in this regard.
Given python’s love for string-leading sigils, the previous commenter should be quite comfortable with the idea of obscure single-letter operators that dictate the interpretation of the following tokens.
With regards to BEGIN
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
If you think that's bad, try learning python or a verbose language while not speaking english, all of these words like while, for, if, else, break are just gibberish and your code just reeks of some weird mish mash of broken english and broken <mother tongue>, I have a hypothesis that terseness favors universality, if you don't speak english, something like $_ is equal or easier to grasp, it honestly just looks like terse and weird math.
That was the idea of APL (and its successors like J and K) -- make programming a math notation rather than pretend to be a human language (generally English, but there have been programming languages with keywords in Chinese and Russian, among others).
You’re mad that you have to look up what keywords do in a programming language you aren’t familiar with? If you think Python is always clear, I can guarantee you (as someone with relatively expert grasp of Bash, Ruby, Go, and once long ago, Perl) that no, it isn’t always obvious.
Yeah, it's true that Perl did not have as a design goal that a complete newcomer should be able to intuitively understand the code without having any prior exposure to the language. There is a little bit of a learning curve, and that was completely expected by Perl's creators. Yes, you have to learn about the idioms above, but they became second-nature. For many of us, the model clicked in our heads and the terseness was worth it. You could express a lot of functionality in very few characters, and if you had invested in learning, it was very quick to grok because common patterns were reduced to familiar abstractions in the language.
And yet, as the industry grew and all sorts of people from all sorts of backgrounds converged in this space, the tolerance and appetite for funky/terse waned in favor of explicit/verbose/accessible. It's probably for the better in the end, but it did feel a little bit like the mom-and-pop store on the corner that had weird pickled things at the register and a meemaw in the back got replaced by a generic Circle K with a lesser soul.
> 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.
Honestly, $_ and "what does a function do when I don't supply any arguments?" are really nice in Perl, and not that difficult to understand. I think a lot of languages could use a 'default variable'.
$_ was one of the things that put me off perl, because the same syntax meant different things depending on context.
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.
When I was choosing between learning python and perl in the late 90's, it was the context sensitivity of perl expressions which really squicked me. To me, that was the critically bad language decision in perl. You can make context-sensitive expressions in python (using operator overloading, for instance), but you have to go out of your way to do it in one way or another. In perl you can easily do it by accident, and it can result in serious bugs. It seemed masochistic, to me.
Seems like the essential criteria is not whether you can write opaque code in it, but rather whether the language enables you to accomplish most tasks using clear, readable code. They aren't mutually exclusive.
Hopefully I am paraphrasing you correctly.
> I'm having to pick up some perl now, and while I don't interact with the community, it surely _feels_ like it was written by wizards, for wizards. Obscure, non-intuitive oneliners, syntax that feels like it was intentionally written to be complicated, and a few other things that feel impossible to understand without reading the docs.
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.
While I'm not a fan of Perl per se, I find it fascinating. One of the reasons for that is that its creator, Larry Wall, is a linguist by trade. This shows in a lot of ways, for example by the fact that, like natural languages, Perl has context: A variable can behave differently whether it is used in a scalar context or an array context. At the same time stuff like this is responsible for Perl's reputation as a write-only language, a cliche which has at least some merit to it.
I can highly recommend reading at least the first chapter of Programming Perl, it's highly insightful even if you don't plan to write or read any Perl.
>>I'm having to pick up some perl now, and while I don't interact with the community, it surely _feels_ like it was written by wizards, for wizards.
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.
> 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?
Do you not? The pace of anthropic/Claude tool development is pretty bonkers, AI hype reminds me of the 90s a lot.
>This was one of the big reasons, most of these enterprise coders wanted Perl gone
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
Yup, Perl is something clearly out of Unseen University, err I mean Berkeley linguistics dept.
I liked it, thought the sigils were a cute way to singal that something is a variable. When you work with deeply nested data structures, dereferencing arrays and hashes that sort of changes and becomes kind of annoying. Nowadays I like Ruby. Compared to it, Perl does feel like spells mixed with C and Posix stuff. But if I want to feel smart, I'll write some code in Scheme, thank you.
This is it. I wrote largish systems in perl using its OO things and that was good.
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.
> 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.
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.
The term "surrogate activity" comes to mind, specifically, activities of no real value that some people like to waste time on to feel better about themselves.
People summit Qomolangma. (with logistics)
[dead]
> I always found the Perl "community" to be really off-putting with all the monk and wizard nonsense
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')
CPAN was inspired by CTAN, the Comprehensive TeX Archive Network.
Perl made a mistake, the language was invested in depth of expression and that, in a programming language, just leads to a 1000 ways to write same thing where like... 2 of them are actually nice to read.
Pyton was ("was" was used here on purpose) the opposite, the whole "one way to do a thing" and insisting on more clean code even if more verbose.
You could write nice looking Perl code but you had to choose to do it, while Python pushed you in that direction from the start.
As much as I dislike using whitespace as flow control it also does make sure the code is always indented reasonably even if it is a newbie just starting in the language.
It didn't help that Perl, just like other languages after (PHP, JS, Python too), had a "curse of the newbie language", with many people starting with it (as at the time it was kinda only sensible choice for webpages before mod_php did a revolution in how most webpages are hosted), with no training and just winging it, which in language that puts no limits on what user can do and no guidance on what they should do... leads to that ugly one liners and line noise as a code scripts.
> the whole "one way to do a thing"
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).
And the Perl way is opposite, which is what my point was? I'm not sure what you want to say here
That is the story that Python tells about itself. Meanwhile, folks who don’t use it every day are constantly learning that it’s only true within a single version of Python, but that over the years there will be multiple, incompatible ways to do niche wild rare stuff like … iterating over a map.
...that's why I used "was". Current direction of the language mostly goes against the "Zen of Python".
Python has never actually followed the Zen of Python, which is one of my gripes with it. For example, "explicit is better than implicit" is a bad joke given how Python implicitly treats non-boolean types as booleans.
I don’t know about the wider Perl community, but I listened to some interviews from Larry Wall and he just came across as a nerdy guy having fun with what he’s doing. I quite liked listening to him.
I was never a perl programmer, but this was my impression of basically every perl programmer I have interacted with.
Also, I think Larry Wall's "Diligence, Patience, Humility"[0] is among my favourite articles about programming.
[0] https://www.oreilly.com/openbook/opensources/book/larry.html
Larry should be remembered for the development of "patch" more than perl. Without the concept of fuzzily applying patches to modified source files you can't have "git rebase" or "git merge".
Larry was (and presumably is, but I'm out of that loop) a gem. The Weird Al of programming languages. Hilarious and kind.
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.
Maybe in retrospect instead of “this isn’t a help channel” it should have said “go to #perl-help for questions” or made #perl be an open forum and moved the wizard discussion to #perl-experts?
My anecdotal experience was with perl guys who were ex-military, irreverent, and fly-by-the-seat-of-your-pants. The Java and .NET guys were straight laced and nerdy.
Individuals are rarely (not never, but rarely) the full problem. Groups of people are what cause feedback loops and cultural reinforcement like the author describes. Sometimes this is a virtuous reinforcement cycle but more often than not the well gets poisoned over time.
I actually think it works when you are in the ecosystem fulltime for a good while.
But having to interact with it once in a while is always a hurdle. The same with bash. Do I use [ or [[? Where does the semi-colon go? if then fi, but while do done (and not elihw). -eq or =? Functions have () but no parameters.
I'm sure those things make sense when all you write is Bash / Perl, but it's daunting.
Now, Python can get pretty far out there too with Meta-programming, and JavaScript can get confusing with prototyping. And Ruby (especially RoR) takes the crown, where they resolve variables at the moment the line executes. Makes debugging blocks really hard.
The less magic in code the better.
>I'm sure those things make sense when all you write is Bash
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.
You realize you can learn all of this easily online, I hope? Sure it turns out that a scripting language maintaining compatibility with scripts from 40+ years ago has some confusing aspects. That’s the price of such incredible staying power.
You can learn them now, but you will forget them soon. That was the point, I believe.
The point is not that such quirks are impossible to learn; the point is that they make the language extremely unpleasant to use.
Perl is a sysadmin language. There's "always" been this tension between sysadmins and developers.
In my mind (developer back then) I'd amateur-psychoanalyze all of that nonsense as some kind of inferiority complex meant to preserve the self image. Needless complexity can be a feature!
And now we are all developers!
> some kind of inferiority complex meant to preserve the self image
Or, as the kids say, a flex, but without the sexy connotations.
(Incidentally, I am also reminded of a great quote attributed to Morphy:
"The ability to play chess is the sign of a gentleman. The ability to play chess well is the sign of a wasted life.")
That quote is not very convincing to me. Both parts of it are questionable.
Just being able to play chess is not a very high bar at all. Most 6-year-olds can learn it in an hour. Are the Chess hustlers at Washington Square Park all Gentlemen?
I don't see being able to play Chess well as any kind of deficiency. It could be that it's just someone's hobby. It doesn't have to mean they spiraled into madness, Bobby Fisher style.
(I can play chess, but not well, so I personally don't care about either half of that quote as it applies to me)
The quote, if originally from Morphy, is from the 1800s, though. So it's the context of the quote that matters.
Either way, it's not meant to be taken so literally!
Morphy, who is probably the greatest chess player to ever live, would probably know.
I think it's a sysadmin thing to have a little bit more wimsy in the code.
Administrative work by nature leaves you a bit bored, if you do it right. So you sometimes pick something up just to play with.
I can't speak about every sysad experience, but in mine a lot of scripts tend to be in a "make once, remember for ten years" category, and even a bit of creative naming can help a long way.
Working with a larger codebase with "creative" code, on the other hand, is frustrating. And if you don't have to write code, you might as well go take a walk, "monitoring" isn't in your job description.
In the 2000’s Python was also a sysadmin language.
Edit: But I see your point, Google SRE’s around the late 2000’s reached for Python more than Perl.
I think Perl is still more popular even today than Python as a sysadmin language. Late 2000s it certainly was. Maybe Google was different, but across the industry more widely Python was barely used, Perl was used everywhere.
My experience:
Sysadmin-driven companies (typically Sun-based) often used Perl.
Developer-driven companies used other languages running on cheaper X86 Linux.
(90s) Yes, but it developed.
As someone who lived through that transition, we used Perl extensively to sysadmin ~30 Solaris and Irix workstations and it was superlative at that.
At that time, Guido was still working at CNRI locally to us in Reston, VA and we had several discussions at the local Pyggies (Python User Group) on transitioning over to Python for that work. We were a (mostly) C++/Java shop, but Perl fit into all the other "crevices" beautifully.
Python just didn't have enough library support for all of our "swiss-army chainsaw" demands. Still, it was very apparent at the time it would eventually get there and I was enamored with its "one right way" of doing things--even at the bytecode level.
I never interacted with any of that, to me Perl was always "Bash with text processing built-in and no string interpolation pitfalls". I reach for it when I need to write one to two page long utility scripts. Python is too willing to deprecate features (plus the whole 2 to 3 fiasco burned me badly), so I only use it for things I know I will maintain. Perl is for writing a shell script that will run unchanged in perpetuity.
This made me smile given Python's love of Monty Python references - the cheese shop etc.
I appreciated them at the time I encountered them (mid-2000s), but they were definitely a bit cringe in their frequency and shamelessness. I wonder if younger people even know Monty Python anymore - by my time, I think people had mostly forgotten about Hitchhiker’s Guide to the Galaxy, even if 42 survived.
As a foreigner I hadn't known Monty Python when I started learning the language and reading the docs, and I haven't noticed any of those. I guess they came across as just noise.
The kids these days have factored 42 to 6,7 (said with some inflection and hand waving)
Did you come up with that? If so, bravo!
6-7? No, my kid says it about a thousand time a day. Then, for some unknown reason they follow it with 41! WTF! I've shouted 42! many times and have tried to inform the child of the significant cultural and scientific importance of 42. Which, IIRC, factors to 2,3,7.
67 and 41 are the TikTok / Gen Z speech.
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.
> 41!
That’s a very big number!
Dude it is not cringe. It is silly.
Pretending to be a all serius grown ups language is cringe.
I agree but don’t forget that the average programmer nowadays is a strait-laced corporate entity, whose personality is Node.js stickers on a macbook, like everybody else in their team.
They forget that Perl and co. were written by people that had one too many tabs of LSD in the 70s, sporting long hair and a ponytail.
I’m going to go out on a limb and guess that Larry Wall, a devout evangelical Christian and the child of a pastor, was not turning on, tuning in, or dropping out in the 1970s.
The syntax problems are just surface. There are some real problems underneath:
Poor performance of the single implementation.
A single implementation.
Leaky ref counted GC, but 'luckily' the syntax for references is so clunky that nobody does anything complicated enough that it really matters.
Bolted on object oriented features that never got the love they needed at a time when oo languages were sweeping the world.
Most of the wizards decamping to a new language (Perl6) that was 'developed' for years without an actual implementation to keep them grounded.
> 'luckily' the syntax for references is so clunky that nobody does anything complicated enough that it really matters.
That made me laugh. Unlike actually working with Perl references, which made me want to cry.
Strange, for me it's the opposite.
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.
Python for awhile had its own cultural issues. I guess, coming from more of a C and lisp background, the stuff you're mentioning seemed playful and fun to me and I didn't get the sense anyone expected to write performance critical code in it anyway.
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.
I've always found Perl just plain ugly, too clever about some things (like iterating over regex matches on stdin or something) and really dumb about other things (variable syntax, the god-awful OOP system). Python is clean and pretty in comparison and usually well thought out. If the communities were reversed, I'd still prefer Python: I just read the documentation in 99% of cases, I very rarely need to interact with the community. Python, as the article says, is mostly not a language for fans - it's mostly for auxiliary tasks.
I liked perl, it was the first language I used daily as a HW engineer. When I moved to python more recently what I missed the most was how easy it was to do a one liner if with regex capturing. That couldn't be done in python for a long time. I think the walrus operator helps, but it's still not quite as concise, but it's closer
Good for you, not for anyone else reading the code or yourself 6 months later. Seen too much of that.
My code wasn't written to be hard to decipher, and it wasn't a goal to get everything on one line by any stretch, I just didn't like an if with regext was 2 lines minimum in python, it felt inelegant for a language that is pretty elegant in general
> I always found the Perl "community" to be really off-putting with all the monk and wizard nonsense.
Rubyists vs. Pythonistas isn't any better.
Programming languages as counter-cultural lifestyle choices is pretty "cringe" as the kids say.
I don't think "Pythonista" was a thing in the 2000s. Python is very old and only became more of a "fad" relatively recently.
I can remember perl vs python flame wars ca. 2002.
Also, the early 2010s are not that recent: https://books.google.com/ngrams/graph?content=Pythonista%2Cp...
It was definitely a thing.
This will keep happening until we start programming computers with some kind of AI style driven interfaces, and even then maybe not.
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.
> Rubyists vs. Pythonistas isn't any better.
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.
oh yeah you're right and this is coming from someone who still likes/uses perl once in a while for text manipulation stuff that awk/sed won't cut it for. try going into your terminal and typing in
And you get this code snippet: man is that ever from a different time... but let me tell you if you can pull off some of those awk/sed or perl one liners you can do some pretty useful things with less resource allocation than you would be spending if you had written that in python, which becomes important if you're running it over and over on terabytes of data or on limited hardware> 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
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 community college our perl professor was often late. One time he just didn't show up. I remember him once saying something like job security involved writing indecipherable code so none of your coworkers could understand it. There was a tinge of bitterness in his remark. Our exams were essentially obscure perl puzzles where we had to read the code and determine the output, some kind of coded phrase.
I loved Perl and all the obscurity. It felt like black magic back then. It should have become what python is today.
actually Perl was what Python is today - the go to scripting language
I have never worked (in Prod) with Perl, but my introduction to programming was with PHP and all I know IMHO is that PHP was/is so easy to start with. One of the reasons I picked PHP over other languages.
Strange, maybe because of being a 70's kid and a D&D nerd, that kind of stuff is exactly why I liked Perl in first place.
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.
First time I read something like that about Perl. Is this personal experience during the Perl peak period or extrapolation from phrases
> None of this is literally serious,
Exactly.
I remember someone telling me to RTFM when I posted a question on IRC back in the 90s. Luckily, I explicitly asked if they were serious. They responded of course not-- they were kidding!
Then they PM'd me with hidden link that had an image map of Perl wizards with whom I could schedule a free meeting and coffee to get started as a newbie. I was skeptical-- who cares about some random noob from the interwebs?!? Well, Perl, apparently. That face-to-face meeting left me with goosebumps that I feel to this day when I think back on it. It turned out to be an important confidence booster and my chief way into programming.
I don't think it's an exaggeration to say that without Perl's focus on outreach I would never have served as president of Software Local 2142.
Like my wizard mentor told me when I tried to pay for the coffee that afternoon: Perl it forward!
I can't tell if this is real or real funny.
Neither?
Looks like slashdot-era copypasta.
... I’ll have you know I graduated top of my class in the Navy Seals, and I’ve been involved in numerous secret raids ...
I need to hear more about this Software Local 2142.
Of course it was cultural. This article covers it all in more detail, but I was coding a lot in this period of Perl's decline, and in hindsight it was all so obvious.
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.
> [..] as a design goal - to make programming fun. There was even for a while in the late 2000s the culture of _why and MINSWAN.
It was a great time - titles like Learn You A Haskell For Great Good and Land of Lisp really capture the zeitgeist.
But could a different culture have actually changed Perl to be friendly and fun like Ruby? Without completely torpedoing compatibility with existing code and essentially creating a whole new language anyway?
Or did the language itself just get outdated and replaced? (there's nothing wrong with that! most things don't last forever!)
I feel like I grokked Perl enough and I still write Perl code, but I also think that there are some technical reasons why it declined in popularity in the 2000s and 2010s. All those differences between $ % @, the idea of scalar or list context, overuse of globals, and references. These features can all make sense if you spend enough time in Perl, and can even be defended, but it creates a never-ending stream of code that looks right but is wrong, and it all seems to create a lot of complexity with very little benefit.
This requires those with power to relinquish authority and/or try new, unfamiliar practices and accept possible failure.
Any company/organization can theoretically change its culture, but it's quite difficult in practice.
> PHP was fast, easy, forgiving. It also led to such awful code that several companies banned it.
That's not the case nowadays with PHP 8.5 for example... and Laravel framework.
I never interacted with the "Perl community" described here. When I used Perl in a past job it was in the "just google for how to do things" era.
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.
> 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.
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.
No, optional type hinting means there's sometimes not a hint. Having a hint and then passing some type that's not that is wrong and hell.
Python's type hinting is horrible.
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's not checked, it's not required,
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.)
That's the problem! The code should not run if the types are wrong. Having an external tool is an antipattern.
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 are talking about misleading type hints, not optional ones. Optional means they don’t have to be added. Wrong typehints are so much worse than missing ones.
I think the purpose of optional type hinting is that you don't have to add it everywhere all at once, not that it doesn't have to be accurate. I guess you could split hairs and say "hint" doesn't imply perfect accuracy, but... adding a language feature that can lie really seems to have a lot of downsides vs upsides; whereas at least optional has obvious migration benefits.
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...)
> 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.
If it's built in to the runtime you get a lot of potential benefits:
- 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?
In fairness, Perl died because it was just not a good language compared to others that popped up after its peak. Sometimes people just move to the better option.
Perl is a great language, the way Scala and Haskell are great: as openly experimental languages, they tried interesting, unorthodox approaches, with varied success. "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say.
Perl is not that good a language though for practical purposes. The same way, a breadboard contraption is not what you want to ship as your hardware product, but without it, and the mistakes made and addressed while tinkering with it, the sleek consumer-grade PCB won't be possible to design.
> "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say.
Perl lets every developer write Perl in their own idiosyncratic way.
And every developer does.
It makes for very un-fun times when I'm having to read a file that's been authored by ten developers over ten years, each of whom with varying opinions and skill levels.
I guess in 2026, it'll be 11 developers writing it over 11 years. My sincere apologies to those who come after me, and my sincere fuck-you to those who came before me. :)
Something I only figured out in the ‘10s is that the main tax of code smells is during debugging. Debugging when taken to the level of art is less about sorting all of the possible causes for a problem by likelihood but by ease of validation.
Things that are cheap to check should be checked first unless they are really unlikely. You change the numbers game from trying to make the biggest cleaving lines possible, to smaller bites that can be done rapidly (and perhaps more importantly, mentally cheaply).
Code smells chum the waters. Because where there is smoke sometimes there is fire, and code smells often hide bugs. You get into Tony Hoare’s Turing award speech; either no bugs are obvious, or there are no obvious bugs.
So I end up making the change easy and then making the easy change because we have more code each week so the existing code needs to be simpler if someone is going to continue to understand the entire thing.
Perl doesn’t seem to have figured this out at all.
Exactly. Perl is about experimenting, trying things your way, and discovering new and good ways to write programs. Which is a wonderful capability for research and discovery, and for art or recreation, but not that great for industrial production.
This is why Perl was quite fit for the job at the dawn, or, rather, the detonation phase of the Internet explosion in late 1980s and early 1990s, along with Lisp and Smalltalk that promote similar DIY wizardry values. But once the industry actually appeared and started to mature, more teamwork-friendly languages like Java, PHP, and Python started to take over.
> in 2026, it'll be 11 developers writing it over 11 years.
Perhaps too, a tool that's been around and in active maintenance for 11 years has been wildly successful.
I wouldn't say "wildly". I would say that it's critical enough to the company's workings that they devote enough resources to it to keep it going, but not enough resources to consider re-writing it or re-factoring it to be easier to work on.
In a similar vein, as the industry matured, we went from having teams of wizards building products, to teams of "good-enough" developers, interchangeable, easy to onboard. Perl culture was too much about craft-mastery which ended up being at odds with most corporate cultures.
Unfortunately, as a former Perl dev, it makes a lot of other environments feel bland. Often more productive yes, but bland nonetheless. Of the newer languages, Nim does have that non-bland feel. Whether it ends up with significant adoption when Rust and Golang are well established is a different story.
It could have used a good "Perl: the Good Parts" book.
With a team where everybody wrote it in a similar style, Perl did perfectly well. Mod_perl was fast. I liked Perl.
Then Django came out, and then Numpy, and Perl lost. But Python is still so incredibly slow....
Check out "Perl Best Practices" by Damien Conway, and the more recent "Modern Perl" by Chromatic. Both can be had as paperbacks, and I think both are also available free on online.
I'll go further. Ignore the Perl specific bits and Conway's "Perl Best Practices" is one of the best general programming books ever written.
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.
Mostly - from here - python is so incredibly slow to write. Who has this kind of time?
Slow to write, slow to run and throws whitespace errors. Surprised it made it so far.
Sounds exactly like academia itself, and is probably a selling point if you’re a business.
It is not a great language.
It is, however, a significant language. It has left a mark and influence on the culture and industry of programming. Nothing to sneeze at.
The big pearl of wisdom I took from Larry Wall seemed to be counter to the culture I experienced looking in from the outside. That always confused me a bit about Perl.
And that was, paraphrased: make the way you want something to be used be the most concise way to use it and make the more obscure features be wordy.
This could have been the backbone of an entire community but they diminished it to code golf.
In two concepts: syntactic sugar vs syntactic vinegar.
Couldn't they have figured out one decent way to do things before releasing features to all users? I tried Scala for a bit then decided it was complicated for no good reason.
Idk about Haskell, but I used Erlang which is also purely functional. No matter how long I used it and tried to appreciate its elegance, it became clear this isn't a convenient way to do things generally. But it was designed well, unlike Scala.
Erlang is, by my accounting, not even a functional langauge at all. It takes more than just having immutable values to be functional, and forcing users to leave varibles as immutable was a mistake, which Elixir fixes. Erlang code in practice is just imperative code written with immutable values, and like a lot of other modern languages, occasional callouts to things borrowed from functional programming like "map", but it is not a functional language in the modern sense.
If you go to learn Haskell, you will find that it has a lot to say about functional programming that Erlang did not teach you. You will also find that you've already gotten over one of the major hurdles to writing Haskell, which is writing with immutable values, which significantly reduces the difficult of swallowing the entire language at once and makes it relatively easier. I know it's a relatively easy path because it's the one I took.
> Erlang is, by my accounting, not even a functional langauge at all.
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.
x = x + 1
always annoyed me as a syntax for binding, when first learning programming, coming from using = in equational reasoning in mathematics.
x: x + 1
would have been more natural as assignment/binding, imho.
Pretty sure FP is exactly what you said. If it's not, I'm ok calling it a "no variables" language.
If you wanted to write a quick on off script then using magic variables,etc made sense. Writing something you’ll keep? Don’t use those. When Perl 5 introduced references they could have simplified the syntax though.
Not really. It wasn’t audacious in service of anything innovative. Haskell takes functional programming to the nth degree, scala tried to be an advanced Java for example better at concurrency.
Perl was an early dynamic (garbage collected) “scripting language” but no more advanced than its contemporary python in this regard.
It had the weird sigils due to a poor design choice.
It had the many global cryptic variables and implicit variables due to a poor design choice.
It has the weird use of explicit references because of the bad design choice to flatten lists within lists to one giant list.
It actually was the one thing you said it wasn’t - a good practical general language at least within web and sysadmin worlds. At least until better competitors came along and built up library ecosystems.
Reasoning through analogies?
There was so much complexity hidden behind "do what I mean". For example, scalar vs array context which was super subtle:
Or even worse:
Which allegedly got a HS kid in hot water[^1].[^1]: "It's all about context" (2001): https://archive.ph/IB2kR (http://www.stonehenge.com/merlyn/UnixReview/col38.html)
I think what's most likely to happen here is that: * a developer that knew how it worked used it in code where he *wanted* to get the first line * someone just starting up copied it over and assumed that's the way to get the content of command into a variable
It's essentially complaining about using feature wrong on purpose, because the person that made mistake never learned the language.
my($var1, $var2...) is a way to multi-assign variables from an array.
and that makes perfect sense when you look at it. Perl have no multiple returns, but if you need a function that returns 2 variables it is very easy to make it work with:
Perl's feature for returning different type depending on caller is definitely a confusing part but returning lines makes perfect sense for the use case (you call external commands to parse its output, and if you do that you generally want it in lines, because then you can just do and it "just works".Now you might ask "why make such shortcuts?". Well, one of big mistakes when making Perl is that it was also aimed as replacement for sed/awk for the oneliners, so language is peppered with "clever short ways to do stuff", and it's a pleasure to use in quick ad-hoc oneliners for CLI.... but then people try to use same cleverness in the actual code and it ends up with the unreadable mess people know Perl for.
the fact you can do
is just the feature being.... consistent in its use "when you give it array, it will fill it with lines from the executed command"you gave it array, and it just did what it does with arrays.
Then don't use the low level interfaces. In Perl, language features are plug and play. Everything's in a module. Use the core module List::Util instead.
That's not super subtle any more than it's super subtle that "*" performs multiplication and "+" performs addition. Sometimes you just need to learn the language.
This is not a general defense of Perl, which is many times absolutely unreadable, but this example is perfectly comprehensible if you actually are trying to write Perl and not superimpose some other language on it.*
There's is no fair comparison to be made here with how + and * work is most languages, precisely because + and * work the same in most languages, while whatever perl is doing here is just idiosyncratic.
Even C gets it's fair share of flack for how it overloads * to mean three different things! (multiplication, pointer declaration, and dereference)
The original statement wasn't that the sigils are unconventional. They are. It was that they were "subtle". They are not.
I always found contextual eval interesting. It's a generalized version of toString in a way
It's funny, because something like
or is less subtle to me but I can't put my finger on why.It's not complexity, it's magic. Useful when one cannot be bothered to write array.length. So is if (@a) when the array is empty.
What exactly is complex or "super subtle" about this? It's the textbook example from the 1st chapter in the tutorial or something?
It's just very non-obvious what the code does when you're skimming it.
Especially in a dynamic language like Perl, you wouldn't know that you're passing down an integer instead of a function until the code blows up in a completely unrelated function.
Then use one of the type systems for Perl.
https://metacpan.org/pod/Type::Tiny
You can't do that if you gave up at the very first sigil puzzle.
I'm fine with that: to program in Perl you need to be able to follow manuals, man pages, expert answers, - and even perl cookbooks, or CPAN or web searches. It's a technical tool. The swiss army chainsaw. It's worth it.
Seems like you and a few other posters are making the article's point – that Perl's culture is hermetic and that new programmers would rather learn Python, Ruby or Javascript rather than figure out which sigil means what.
I wouldn't call it hermetic in that the many forms of documentation are insanely thorough and accessible - if not well advertised. There is no gate-keeping (from my point of view). New users are welcome. It's easy to learn (for the people for whom reading is not an obstacle).
But yes, no contest that the world has been on a simplicity binge. Python won by pushing simplicity and by having giant software corporations choosing it (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.
> it was just not a good language compared to others
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.
I agree and Steve Yegge covered the reasons well here: https://sites.google.com/site/steveyegge2/ancient-languages-...
His point about references is no small thing. Other dynamic languages don’t make users think much about the distinction between references and values at the syntax level. With Perl you needed to use “->” arrow operator frequently if and only if you were using references. So getting at a map inside an array or vice versa had its own syntax vs reading a string in a map or array.
Also it had bolted on, awkward OO on top of the bolted on, awkward params passing. You literally had to shift “self” (or “this”) off a magical array variable (@_).
By default it wouldn’t warn if you tried to read from an undeclared variable or tried to use one in a conditional or assign from one. You had to declare “use strict;” for that. Which wasn’t hard! But these awkward things piled up, a bunch of small cuts. Don’t forget “use warnings;” also, another thing to put at the top of every Perl file.
To the extent its awkward syntax came out of aping of shell and common Unix cli tools, you could maybe see it as cultural issue if you squint.
But any language in the mid 90s was infected with the “rtfm” priesthood vibe the author writes about, because the internet then was disproportionately populated by those sysop types, especially the part that can answer programming language questions on usenet, which is basically where you had to ask back then.
So for example Rails won for technical reasons, it is much more concise with fewer footguns than its Perl equivalents. I was actively coding web stuff in Perl when it came along and early switched. It wasn’t a cultural thing, having choice in Perl was fine (and ruby has sadly never grown much culture outside Rails - it could really use some). It probably did help that it came along in the mid aughts by which time you could ask questions on the web instead of Usenet. And it used YouTube for that first rails demo. So ruby did end up with a less sysopy culture but that had more to do with the timing of its success than the success itself.
> bolted on, awkward params passing
Shell had to do this because of shell reasons, like how you need spaces where you shouldn't. Perl post-dated C by over a decade, so there was no reason for goofy argument unpacking.
Yes there was a reason as Perl took inspiration from Lisp - everything is a list- and everyone knows how quick C's variadic arguments get nasty.
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.
Perl was developed in 1987, the first Common Lisp standard was released in 1984, 3 years earlier. Common Lisp allows arguments like so:
Not only normal arguments like we get in C or Pascal, but there's keyword arguments, you can have optional arguments, and a rest argument, which is most like Perl's @_. And that's not even getting into destructuring lambda lists which are available for macros or typed lambda lists for methods.Although Perl auto flattens lists by default, which isn't particularly lisp like.
Perl was (and still is) a very expressive and concise language for working with text and a unix-style system. It exists in the odd space between a shell language and a general purpose language.
But, shell scripting has already become somewhat of an arcane skill. I think the article nailed that Perl was just too hard to learn for the value it provided to survive. Python is not nearly as, erm, expressive as perl for working in that space, but it is much easier to learn, both in terms of reading and writing. In other words, it encourages broadly maintainable code. Ruby is quite similar (although I think people massively overstate how much the language itself generally encourages understandable semantics)
> Perl was (and still is) a very expressive and concise language for working with text and a unix-style system. It exists in the odd space between a shell language and a general purpose language.
GvR explicitly describes the motivation behind Python in similar terms (I can probably find a timestamp in that recent documentary for this). But the goal there was to be fully "general purpose" (and readable and pragmatic, more than artistic) while trying to capture what he saw as the good things about shell languages.
And it's changed quite a bit since then, and there are many things I would say with the benefit of hindsight were clear missteps.
We all joke about the hard problems of computer science, but it seems to me that the hard problems of programming language design, specifically (and perhaps software engineering more generally?) include having good taste and figuring out what to do about reverse compatibility.
> I think the article nailed that Perl was just too hard to learn for the value it provided to survive. Python is not nearly as, erm, expressive as perl for working in that space, but it is much easier to learn
The use cases have also changed over time. Quite a lot of developers ended up on Windows (although that pendulum is perhaps shifting again) where the rules and expectations of "shell" are very different. To say nothing of e.g. web development; long gone are the days of "cgi-bin" everywhere.
Shell is a crappy scripting language because it has primitive data structures and data flow control making it hard to manage and manipulate data as you process it between applications. The fact that newlines are such a problem is a case in point.
Python is a crappy shell scripting language because the syntax around pipe and subprocess is really clunky.
Perl managed to have decent data structures and also have decent syntax around subprocess calls.
But I feel like the Python invoke module gives me everything I need wrt subprocess calls. I basically write any nontrivial "shell script" these days as a Python invoke command.
I assume you refer to https://www.pyinvoke.org/ which I just looked up. It looks quite promising, thanks for the heads-up.
> Perl was (and still is) a very expressive and concise language
And that could be one of major reasons why it lost in popularity. It was and still is easy to write but hard to read.
When I learned perl, I encountered a way to express myself more easily than any other language. For example, being able to say not only "if foo" but "unless bar" gave me a more fluid vocabulary to get things out of my head and into code.
Thing is, it worked great for ME but when I started interacting with other people's perl code, it all broke down.
One person would write it all on one line. Another would be extra verbose. Some would use all the idioms, others would be 10 levels of nested braces.
Every person's brain expressed itself differently and it was much harder to find common ground.
Eventually I left perl for python, which seemed to be more sane. It seemed pythonic was more of a thing and the code was more readable. Also, it had a large standard library and you didn't have to leave the language to solve just about any problem. It did require extra effort to write code, but the benefits were pretty obvious.
A couple other sort of random points - perl 6 was delayed and that might have hurt the language. Just the same python 3 did come out, but the 2 to 3 changeover was a huge negative to the language.
Exactly. Perl did regexes very well. It did basic hash tables okay. It did everything else poorly.
Once languages came along that did okay regexes and good hash tables along with getting other stuff decent, Perl just got pushed aside.
Yeah I think I would have been considered part of the “in” crowd of Perl to some degree and it wasn’t the culture that drove me away and to Python.
It was Django and the people involved with it.
> and the people involved with it.
Culture?
Perl was my first favourite programming language, used it for most things, from 1999 until switching to Python in 2012.
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.
[dead]
I was a fairly heavy user of Perl, but eventually migrated to Python. The primary reason was the generally abysmal quality of what was in CPAN compared to what was available as third-party packages for Python. I found myself having to spend way too much time fixing stuff I pulled down from CPAN far more than I'd need to for Python for the same functionality. Undoubtedly Perl stuff got better, but I didn't have time to wait.
I mainly moved on to Python because the startup time for scripts seemed to be a lot worse for Perl. I was a heavy Perl user in the 90's and early 2000's.
No. Perl died because other languages starting having an equivalent to CPAN and its extremely flexible syntax does not scale for medium to large team coordination.
It does if you restrict flexibility, but one of the critical flaws in Perl culture was the belief in letting everyone evolve in different directions while cooperating. It’s a genuinely charming belief, but it’s also explicitly incompatible with ‘interchangeable parts’ employment, and tends to only work in an environment where every individual is the ‘wizard’ lord of their personal domain over code. Even if you managed to train everyone to parse Perl, the cognitive overhead of having to train everyone in each other’s syntactic decisions was O(2^n) expensive, which contrasted quite sharply with Python moving that expensive cognitive overhead to the Proposals system while the produced language had slow version updates and “What we argued about so you don’t have to retread the same ground at work every quarter” mission briefs.
One can say the same for C++.
Yup. An explicit 'sane' subset of C++ can trivially linted and enforced. Sadly, the same can not be said for Perl.
Some of the reasons why I never bothered with Perl was that I had the perception that it, like Ruby, encouraged mutating and modifying classes on the fly, willy-nilly. And the lack of static typing. Python also did not have static typing (it has some optional typing now or something like it), but my perception was that monkeypatching was not abused as much in Python as it might be in Perl and Ruby. Not that I used Python a lot.
Perk was never much interested in fiat-enforced restrictions. That was considered to be the domain of local policy in a given project or team and not something to declare upon its users. We’ve since determined in programming that restrictions can exceed the value of perfect freedom (cf. Rust, TypeScript vs. C, Perl). But for scenarios where rapid flexibility is key (eg. ops eng, sans sre/k8s/etc) the flexibility is more important than the restrictions. Always have an adjustable wrench alongside your fixed-jaws, just in case.
Regarding restrictions vs. perfect freedom, I think it's also about trade-offs, implementation quality, etc. Typescript has very easy and well-defined escape hatches. Conversely, Rust's escape hatches are an active research field, not well-defined, considered significantly difficult by prominent Rust figures, the safety is leaky (for instance no_std), etc.
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.
I switched to ruby because of the quality of the MRI for writing extensions. It was literally a revolution. No more SWIG, no more complex type magic, no more struggles to compile my module on end users systems. This was all wrapped by up gem as well so the switch was genuinely impossible to avoid.
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.
>>Perl died because other languages starting having an equivalent to CPAN
Last time I checked apart from npm, no other language has anything similar to CPAN.
PyPI doesn't count? (or rust's cargo)
or rubygems
> if difficulty itself becomes a badge of honour, you've created a trap: anything that makes the system more approachable starts to feel like it's cheapening what you achieved. You become invested in preserving the barriers you overcame.
The mentality described here has always galled me. Half the reason I’m willing to scramble up these hills is to gain the perspective to look for an easier way up the next time. It’s my reward for slogging through, not for the gathering of sycophants.
I’m not sure you’ve mastered a thing until you’ve changed the recipe to make it a little bit better anyway. My favorite pumpkin pie recipe, isn’t. As written the order of operation creates clumps, which can only be cured with an electric mixer. You shouldn’t need an electric mixer to mix pumpkin pie filling. If you mix all the dry ingredients first, you get no clumps. And it’s too soupy. Needs jumbo eggs, not large. So that is my favorite recipe.
But maybe this is why I end up writing so many tools and so much documentation, instead of hoarding.
Perl was of a time, so it's important to remember when it was around. CPAN was legitimately one of the first package managers for a programming language that WORKED. Contextually, its references are bash, sed, awk, and other cli tools. There are too many ways to do things in perl because of the various flavors / takes on how to do things. It was also a fun way to write cgi apps in the era of C/C++. Is that the best way to do things today? No! It was one way to do something complex in few lines of code. It was the python of its day in many ways.
There are tons of quirks that are interesting that influenced language development today, for me the spaceship operator "<=>" was a fun one. You can have a flip through the camel book to see what kind of stunts were common in its era.
It is an auteur language that was not really done the way languages are today.
Perl 6 did massive damage to the community mainly because it was so different that it looked like a fantasy language. That along with Parrot really lost the plot for me, I had mostly stopped doing that kind of work and moved on to R for my bioinformatics things. Bioconductor was the bees knees.
I'm surprised at all the haterade, probably you're either <30, and/or being overly critical of a very nascent tech era. Perl was pre and post .bomb, and had one of the first online communities that I remember that shared tips and tricks at scale at perlmonks.org. It predated stackoverflow! It was a very different time to now.
This was also from a time when people still paid for compilers(!)
I am deeply biased, as I wrote a 3d distance calculator in Perl for small molecule drugs. We were looking for disulfiram analogs doing biopanning and then simulations. There was a great PDB library for structures at that time that saved me tons of time. This was circa 2005~, ages from now.
I think it's worth pointing out that Python only became popular after Google started using it. Remember when every nerd on the web was an ardent defender of Google? When people wanted to reach for a new language (say, for data science, also a new thing at the time) they reached for that slightly obscure yet easy to learn language that the cool tech company used. Schools adopting it exposed it to more people, but they picked it up, again, cuz Google used it and it was easy to learn.
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".
There was a lot of pressure in the Perl community to write things as succinctly as possible instead of as maintainably and understandably. That’s not realistic for use in a field with a lot of turnover and job hopping.
Yeah the joke was, Perl is write-only.
Write-only perhaps, but with perl you only have to write it once and it'll run forever, anywhere. No breaking on updates, no containers, no special version of Perl just for $application, just the system perl.
Because of this, in practice, the amount of system administration mantainence and care needed for perl programs is far, far less than other languages like python where you actually do have to go in and re-write it all the time due to dep hell and rapid changes/improvements to the language. For corporate application use cases these re-writes are happening anyway all the time so it doesn't matter. But for system administration it's a significant difference.
There was really only one big forced rewrite, 2->3, and ironically Perl was killed by failure to do the same with 5->6.
I agree that python versioning and especially library packaging is the worst part of the language, though.
Agreed! My father (RIP) absolutely loved Perl and could do amazing things with it in seemingly impossibly-few characters. I got reasonably proficient w/ regex but never came close to his wizardry. Much respect for those in his rarified company.
Aren't perl modules locked to the exact version they were compiled in ?
I've met many time some error "haha nope, wrong version, perl 5.31.7 required"
Pure perl modules are not, unless they use syntactic features that first appear in the newer versions.
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.
There was no such pressure. That's ridiculous. There were a lot of things people could grab as reasons to form an opinion without even reading articles, never mind the tutorial. They then ended up with php or python, even java for crying out loud, and years later THAT was a problem.
There wasn't pressure to write concise code exactly, but if you posted your code somewhere the odds were good that somebody would reply with a way to do the same thing with less code, followed by someone else who managed to shave several lines/characters off of that, etc.
While almost all of the time it was all just people having fun (perl is fun and play was encouraged) and not an admonishment of the code you'd posted or an example of how it should have been written I can see how some folks might have gotten that impression. Especially if they were new to perl and were more used to languages where TIMTOWTDI wasn't thing
Code golfing originated in perl.
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...
> There was strong cultural pressure to be able to write perl in as few bytes as possible
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.
One-liners is one of the ways you can use perl. You can also use it as the embedded language in some larger project. As perl CGI. As mod_perl. etc. There is no "cultural pressure" to use any of these. You can choose to mess around with one-liners and you can choose to spend time shaving a few characters off your code. Or not. None of this is the one true way. This is not python.
Code golfing originated in APL.
> There was no such pressure. That's ridiculous.
I lived it. I'm sure there's still some Mailing List archives and IRC snippets that still endure, demonstrating the utter vicious 1-upmanship of how to do something in Perl as succinctly as possible. Why do X and Y when you can just do Z? What are you really trying to do? etc.
You COULD, if you wanted, and spent quite a bit of effort in the pursuit of that hobby, participate in one-liner, or obfuscation, or golfing friendly contests. Which were enabled by perl's expressiveness constructs. Nobody pushed anyone into that. On the contrary "there is more than one way to do it" was there to legitimize that getting the problem solved was the goal - instead of trying to force a one true way (like python).
After that, experts would often propose multiple ways to do something when they answered questions. THEY found that intellectually playful and exciting. They still do. And for the rest of us, that was an amazing way to learn more and understand more of that tool we were using daily. Still is.
You apparently saw viciousness in this and that certainly sucks.
Those experts were horrendously vicious. I can name them and can still describe their dismissive cruelty, since I spent ten years socializing nonstop in the Perl5 core communities (and have a CPAN id, and have an Authors entry in Perl5 core). Think “Linus before he learned to stop insulting people’s worth and focus on critiquing their work instead”. It was absolutely intended as a form of cultural propagation: I can do this more succinctly, so You Should Be Ashamed Before Me. If somehow you weren’t exposed to that aspect of it, I envy you.
Interestingly, that same prideful “my way is so obviously better that it’s a ridiculous waste of my time considering yours” ended up carrying forward to Mozilla, which was launched in part by cultural exports of the Perl5 conservative-libertarian community, and for a decade developer hiring was filtered for cultural sameness, leaving a forest of TMTOWTDI trees that viewed meadows as an aberration to be reforested back to their sameness.
You indeed ran into toxic environments. I don't feel that the common, new perl programmer intake path was anything like that. Not what I ever ran into.
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.
Don't forget many people were still on dial-up and long forum posts were probably discouraged in favor of RTFM or other terse reply.
It was primarily the exhaustion of experts at tireless waves of newbies who hadn’t studied the available materials.
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.
It was EFnet/#perl which included most of the core development team. I don’t really have experience with the non-core social environment, sorry.
Perl's "decline" saved it from a fate worst than death: popularity and splitting into dozens of incompatible versions from added/removed features (like python). Instead Perl is just available everywhere in the same stable form. Scripts always can just use the system perl interpreter. And most of the time a script written in $currentyear can run just as well on a perl system interpreter from 2 decades ago (and vice versa). It is the perfect language for system adminstration and personal use. Even if it isn't for machine learning and those kinds of bleeding edge things that need constant major changes. There are trade-offs.
This kind of ubiquitous availablility (from early popularity) combined with the huge drop-off in popularity due to raku/etc, lead to a unique and very valuable situation unmatched by any other comparable language. Perl just works everywhere. No containers, no dep hell, no specific versions of the language needed. Perl is Perl and it does what it always has reliably.
I love it. The decline was a savior.
Perl's binary brings with it the ability to run every release of the language, from 5.8 onwards. You can mix and match Perl 5.30 code with 5.8 code with 5.20 code, whatever, just say "use v5.20.0;" at the start of each module or script.
By comparison, Python can barely go one version without both introducing new things and removing old things from the language, so anything written in Python is only safe for a a fragile, narrow window of versions, and anything written for it needs to keep being updated just to stay where it is.
Python interpreter: if you can tell "print" is being used as a keyword rather than a function call, in order to scold the programmer for doing that, you can equally just perform the function call.
> By comparison, Python can barely go one version without both introducing new things and removing old things from the language
Overwhelmingly, what gets removed is from the standard library, and it's extremely old stuff. As recently as 3.11 you could use `distutils` (the predecessor to Setuptools). And in 3.12 you could still use `pipes` (a predecessor to `subprocess` that nobody ever talked about even when `subprocess` was new; `subprocess` was viewed as directly replacing DIY with `os.system` and the `os.exec` family). And `sunau`. And `telnetlib`.
Can you show me a real-world package that was held back because the code needed a feature or semantics from the interpreter* of a 3.x Python version that was going EOL?
> Python interpreter: if you can tell "print" is being used as a keyword rather than a function call, in order to scold the programmer for doing that, you can equally just perform the function call.
No, that doesn't work because the statement form has radically different semantics. You'd need to keep the entire grammar for it (and decide what to do if someone tries to embed a "print statement" in a larger expression). Plus the function calls can usually be parsed as the statement form with entirely permissible parentheses, so you have to decide whether a file that uses the statement should switch everything over to the legacy parsing. Plus the function call affords syntax that doesn't work with the original statement form, so you have to decide whether to accept those as well, or else how to report the error. Plus in 2.7, surrounding parentheses are not redundant, and change the meaning:
The incompatible bytes/string handling is also a fundamental shift. You would at least need a pragma.> Can you show me a real-world package that was held back because the code needed a feature or semantics from the interpreter
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:
> Compared to Python's deliberate policy, which is they won't guarantee your code will still run after two minor releases
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.)
asyncio.get_event_loop ?
I seem to have messed up my italics. The emphasis was supposed to be on "from the interpreter". asyncio.get_event_loop is a standard library function.
Well isn't that nice. The boxes I care most about are 32 bit. The perl I use is 5.0 circa 2008. May you amiga386, or anyone else, thank you in advance, may be able to tell me what do I need to upgrade to perl 5.8? Is it only perl 5.8 and whatever is the contemporaneous gcc? Will the rest of my Suse 11.1 circa 2008, crunch? May I have two gcc's on the same box/distro version, and give the path to the later one when I need it? The reason I am still with Suse 11.1, is later releases broke other earlier things I care about, and I could not fix.
suse 11.1 includes perl 5.10: https://ftp5.gwdg.de/pub/opensuse/discontinued/distribution/...
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.
I assumed 5.0 was referring to using any of the 5.00x series.
The Python approach seems better for avoiding subtle bugs. TIMTOWTDI vs "there should be one obvious way to do it" again.
What incompatible versions of pythons do you mean? I'm entirely unaware of any forks, and the youngest version I have to supply at the moment is 3.9, which is over 5 years old and available in all supported platforms.
Try to run any random python program of moderate dep use on your python 3.9 system interpreter without using containers. Most likely you'll have to use a venv or the like and setup a special version of python just for that application. It's the standard now because system Python can't do it. In practice, pragmatically, there is no Python. Only pythons. And that's not even getting in to the major breakages in point version upgrades or the whole python 2 to 3 language switch.
> Most likely you'll have to use a venv or the like and setup a special version of python just for that application.
Using venvs is trivial (and orders of magnitude more lightweight than a container). And virtually every popular package has a policy of supporting at least all currently supported Python versions with each new release.
You need to set up a venv because of how the language is designed, and how it has always worked since the beginning. Python doesn't accommodate multiple versions of a package in the same runtime environment, full stop. The syntax doesn't provide for version numbers on imports. Imports are cached by symbolic name and everyone is explicitly expected to rely on this for program correctness (i.e., your library can have global state and the client will get a singleton module object). People just didn't notice/care because the entire "ecosystem" concept didn't exist yet.
I have at least one local from-source build of every Python from 3.3-3.14 inclusive (plus 2.7); it's easy to do. But I have them explicitly for testing, not because using someone else's project forces me to. The ecosystem is just not like that unless perhaps you are specifically using some sort of PyTorch/CUDA/Tensorflow related stack.
> It's the standard now because system Python can't do it.
Your system Python absolutely can have packages installed into it. The restrictions are because your Linux distro wants to be able to manage the system environment. The system package manager shouldn't have to grok files that it didn't put there, and system tools shouldn't have to risk picking up a dependency you put there. Please read https://peps.python.org/pep-0668/, especially the motivation and rationale sections.
> major breakages in point version upgrades
I can think of exactly one (`async` becoming a keyword, breaking Tensorflow that was using it as a parameter name). And they responded to that by introducing the concept of soft keywords. Beyond that, it's just not a thing for your code to become syntactically invalid or to change in semantics because of a 3.x point version change. It's just the standard library that has changes or removals. You can trivially fix this by vendoring the old code.
> And that's not even getting in to the major breakages in point version upgrades or the whole python 2 to 3 language switch.
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 language learning trajectory (from 10 years old) was 8086 assembly, QBASIC, C, Perl, Java, MAGMA, JavaScript/HTML/CSS, Python, Haskell, C++, vibe coding
How old are you now? Mid fifties here. And 'vibe coding' in what exactly - it is not of interest from a programming perspective, but from a 'what does the AI know best perspective'? I've followed a similar, but not identical trajectory and now vibe in python/htmx/flask without needing to review the code in depth (NB internal apps, not public facing ones), with claude code max. Vibe coding in the last 6-8 weeks now also seems to make a decent fist of embedded coding - esp32/arduino/esp-32, also claude code.
35–44. Same thing, sometimes it makes planning errors, or misses context that should be obvious based on the files, but overall a huge booster. No need to review in depth, just set it against tests and let it iterate. So much potential, so exciting.
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.
I'm not sure about the Perl-specific claims here, but it is amusing how pervasive "on one or more occasions, I got a dopamine release after managing to struggle through the horror and misery of X: now I'm convinced that X is Good, Actually" seems to be in computing.
But isn't this everything? All of computing is a struggle for me at least, all followed with confusion and "Why did they make this, this way?"
But is it all equally a struggle? Some things are definitely more of a struggle than others. Remember xfree86config? We used to have to manually configure our screen resolution in a shitty text file. I even remembered that you had to specifically add a line to tell it you had a 3 button mouse. This was in the late 90s, maybe early 00s. Way after it was sane to have to do that.
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.
One of those many cases where X = X.
I didn't have this experience when I first learned C#. Everything just kind of worked the way I expected it to. There are sharp edges, but far fewer than expected and always for an actual reason.
My first and only experience with Perl was like this: in 1997, just for fun, I tried to write a program in Perl to turn my Mozilla bookmarks into a website. After a week of not succeeding, in frustration I decided to try Python. In two days I had what I wanted, and programming it was a joy. That sealed my judgement that Perl (and all of its culture) was not for me, so I'm not surprised at all that others might feel the same. (To be fair, there's a single oneliner that does make life a lot easier: ... | perl -pe 's{...}{...}')
I hope this doesn't come off as argumentative. You said that with Python "In two days I had what I wanted", but another way of looking at it: in a week of not succeeding in Perl plus those two days in Python, you had what you wanted.
I tried to learn perl a few times early in my career, we still had some old perl internal sites and a bit of tooling written in it. I really struggled to find good resources on the web at the time, and most of the perl I was exposed to was so badly written as to be incomprehensible to me. I knew C and Python at the time.
I wonder how common my experience was and why the next gen (at the time) I was part of never learned it
I had the exact same experience. The Perl I encountered early in my career seemed hard to understand in way other languages weren’t. I also didn’t feel I made progress quickly trying to learn it, every time I thought I had my feet under me I’d encounter a new sigil or a new pattern and be back to having no idea what the code was doing.
Spot on: the toxic culture around the language was a nail in its coffin.
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 cult of RTFM is so painful to interact with and off putting. The concept is sound, reading documentation is important. However simply responding to all questions with "RTFM" is not only not helpful but as often as not useless advice.
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.
> [TIMTOWTDI] literally means 'there is more than one way to do it in Perl' - and you can perhaps infer from that that there's little to no reason to do it using anything else
Not my experience at all, FWIW. For me, and the vast majority of Perl devs I’ve worked with over the past 30 years, TIMTOWTDI absolutely means some of the “ways to do it” don’t involve Perl, and that’s not only OK but expected. Of course Perl isn’t the be all/end all. It’s a lot of fun though!
(I’m a majority Perl coder to this day, it’s my favourite language by far. Hell, I even find it readable and easy/fun to debug)
How popular was/is monkeypatching in Perl?
It is possible to do so, but it stands out in a way such that most people aren't doing it using direct language features unless necessary. If you have `strict` and `warnings` enabled, which is recommended, then the interpreter can give runtime warnings or compile-time errors if you try to manipulate the symbol table or redefine a function. If you still want to use those on a case-by-case basis, you have to turn off those pragmas within a scope. So there are built-in ways the language discourages using them arbitrarily.
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.
Very. I use `Test::MockModule` (not just in tests) or `Sub::Override` or `Class::Method::Modifiers` a lot, according to convention/style or as I see appropriate — but there are, of course, tons more ways to do it.
Rather than its "decline was", Perl's existence is cultural. All programming languages (or any thought tools) are reflections and projections of the cognitive values of the community who creates and maintains them. In short, the Perl language shares the structure of the typical Perl dev's mind.
A shift to Python or Ruby is fundamentally a shift to a different set of core cognitive patterns. This influences how problems are solved and how sense is made of the world, with the programming languages being tools to facilitate and, more often than not, shepherd thought processes.
The culture shift we have seen with corporations and socialized practices for collaboration, coding conventions, and more coincides with the decline of a language that does in fact have a culture that demands you RTFM. Now, the dominant culture in tech is one that either centralizes solutions to extract and rent seek or that pretends that complexity and nuance does not exist so as to move as quickly as possible, externalizing the consequences until later.
If you've been on this forum for a while, what I am saying should seem familiar, because the foundations have already been laid out in "The Pervert's Guide to Computer Programming", which applies Lacanian psychoanalysis to cognitive patterns present in various languages[1][2]. This explains the so-called decline of Perl—many people still quietly use it in the background. It also explains the conflict between Rust and C culture.
As an aside, I created a tool that can use this analysis to help companies hire devs even if they use unorthodox languages like Zig or Nim. I also briefly explored exposing it as a SaaS to help HR make sense of this (since most HR generalists don't code and so have to go with their gut on interviews, which requires them to repeat what they have already seen). With that stated, I don't believe there is a large enough market for such a tool in this hiring economy. I could be wrong.
[1] [PDF] -- "The Pervert's Guide to Computer Programming" https://s3-us-west-2.amazonaws.com/vulk-blog/ThePervertsGuid...
[2] [YouTube Vulc Coop]-- https://www.youtube.com/watch?v=mZyvIHYn2zk
This is interesting to me, as someone moving from a company that uses C++ to one that uses Rust. It feels like the whole culture of the former company is built similarly - no guardrails, no required testing, or code review, minimal "red-tape".
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.
>The Pervert's Guide to Computer Programming
That's a rather glamorous piece of discourse, yall aint sleepin
Sorry for this repetition, but how popular was/is monkeypatching in Perl?
I think a big part is does someone starting to program even hear that Perl exists? No, and they start learning python and so have little need to learn Perl after that
That's why it has stayed dead. But that can't explain how it died. People don't just spontaneously stop hearing about the existence of a programming language in common use.
How did vbscript die? How did php die? Better alternatives came along and sucked up the oxygen.
Which is (sadly) hilarious because that was the reason most people seem to have gone with python: they were told "this is what we use here" or they bought the "line noise" nonsense. They never put much effort into this.
But I also think that people who are truly interested in programming immediately learn that there are many different paradigms. And the net makes it dead easy for them to explore different directions and, I don't know, fall in love with haskell or something. Perl is plenty visible enough for THAT. I don't know about perl 6 / raku though.
I spent year developing CMS in Perl in 1999 (HTA application with ActivePerl. wonder if anybody else did something like this). It traumatized me, and first thing that I did in my next job is to learn python and develop some core systems in it. Few of my friends moved from perl to python as well.
I still remember spending time with my coworkers on bench outside of building trying to figure out #@$%$^&$%@something = []sd[dsd]@$#!&lala lines written by previous developers
Before I eventually switched to PHP, I ended up writing multiple CMS-like solutions that would run via `cgi-bin` but write contents to the webroot (what we would now call a static site generator). As I was quite limited with the standard shared hosting at the time, I ended up inventing my own single file database format (it was a simple text file) to keep state. It worked quite beautifully and kept me afloat for the first few years of my life as a web developer around the early 2000s.
I was aware of ActivePerl and quite liked Komodo. Thankfully I could keep myself from doing things on Windows/IIS apart from a brief stint writing a single file CMS in ASP.
I wrote php2 + msql before starting in that company (and a bit of php3). Like in your case it was essentially static site generator but the management part was HTA (application hosted in internet explorer. you could write one using whatever activex/language: vbscript, python, perl).
as backend we had oracle. at first we tried oracle/linux (just released). but we never managed make it work (oracle engineers that came to us failed as well). So we got dedicated sun server for it.
One day I was bored, installed mysql on my workstation, made a changes in couple of queries and all of sudden i got x20 performance of sun box with oracle. Lead developer said that it's bad solution as mysql doesn't properly supports referential integrity (we didn't actually used it in oracle iirc)
Yesterday I used `pwgen` to role a random password, and at first glance I legit thought it might've been working Perl code. I'm not even slightly kidding.
Perl heads are downvoting you but I agree as a longtime ex Perl user that the sigils were noisy nonsense.
The original intent was you could see var types with them - $scalar, @array, %hash.
They immediately broke this by deciding the sigil would apply to the value /extracted/ from the data structure. So you declared array @foo but accessed an element as $foo[1]. What? There’s a logic there but already you’re violating many people’s expectations so why even have them. The sigils are now confusing many people instead of clarifying anything.
The sigil idea then /completely/ failed when they introduced references and “complex data structures” (nesting arrays within arrays like every other language - in Perl this was a special thing because they had been flattening lists by default so no way to put one inside another).
So now to get at a hash in a hash you used not % but $ since a reference is a scalar. $hash1->$hash2->{“key”}. Versus $hash3{“key”} for a simple hash. Just awful noisy syntax. Due to poor language design up front.
Oops last example should be $hash1->{“hash2”} - this is a whole hash referenced with $ because of the implementation detail that it is in hash1 as a reference, which is considered a scalar.
Technically you are allowed to use % like so: %{$hash1->{“hash2”}}. Which, just - lol.
That last paragraph got me off Perl to Python. The first time I wrote Python like hash1[hash2]["key"] and it worked, then tried hash1[hash2]["array_name"][3] and it worked because that's the obvious way to write something, I fell in love and never looked back.
I never wanted to have to reason my way through chasing pointers through nested hashrefs again.
Before that job in perl i wrote asm/tcl/delphi/c/php (and bunch of other languages after).
This perl syntax caused some kind of rejection on almost physical level. It was same for many of my friends. "Zen of python" was a breath of fresh air.
and people wonder why raku had so many things it needed to change to free the excellent core of the language and its ideas
The lede says Perl died because it was "reactionary" and "culturally conservative", but the content says Perl died because it had bad culture, the culture of angry, socially corrosive anonymous internet commenters.
If Perl had had a good culture, then conserving it would have been good!
That was effectively the culture of the Internet in general at that time. It was the "wild west" for years, because, well, it _was_ a modern incarnation of the same phenomenon.
A good culture, as time goes, is not reactionary and conservative, if only because it opens itself to the contribution of the younger generations.
[flagged]
For me it wasn't cultural.
Perl was my first language because I wanted to make interactive websites and that was the most common way to do it in the late 90s. Shortly after, everyone switched to PHP because mod_php was much faster than Perl CGI scripts.
Surely the people who had purely performance problems with Perl CGI scripts moved to mod_perl? I didn't figure out when mod_php was introduced from casual searching, but given that mod_perl is only a year younger than PHP it must've been available to almost anyone who was considering rewriting their app in PHP. So I have to imagine there were additional reasons.
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...
mod_php was distributed w/ Apache httpd, so it was "already installed". mod_perl needed to be installed manually, so it posed immediate friction, if not a complete freeze-out, depending on the situ. I believe that was why PHP became popular.
Systems with mod_perl (or just Perl allowing normal CGI) installed, especially shared hosting was so common as to be the norm in the late 90s and early 00s.
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".
Perl CGI scripts were ubiquitously supported by shared hosts, but IIRC mod_perl was not unless you had some custom setup on a dedicated server. Also IIRC, mod_perl was just a lot more complicated to set up and use, while mod_php was dead simple.
Perl6/Raku killed Perl.
Python 3 almost killed Python.
It's normal. Once a community loses faith, it's hard to stop them from leaving.
I'd take this a step further and say that the design flaws that motivated Perl6 were what really killed Perl. Perl6 just accelerated the timeline.
I do imagine a saner migration could've been done - for example, declaring that regexes must not start with a non-escaped space and division must be surrounded by space, to fix one of the parsing problems - with the usual `use` incremental migration.
Yep. Perl 6 was a wall that Perl 5 would never move beyond. It’s still Perl 5 25 years later.
Agree 100%. We were told to wait for any improvements or new features we wanted and just to wait for Perl 6, which never came
"Perl6/Raku killed Perl."
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.
Excellent point in the last paragraph. Python, JavaScript, Rust, Swift, and C# all have/had business models and business advocates in a way that Perl never did.
Do you not think O'Reilly Associates fits some of that role? It seemed like Perl had more commercial backing compared to the other scripting languages if anything at that point. Python and JavaScript were picked up by Google, but later. Amazon was originally built out of Perl. Perl never converted its industry footprint into that kind of advocacy, I think some of that is also culture-driven.
Maybe until the 2001 O'Reilly layoffs. Tim hired Larry for about 5 years, but that was mostly working on the third edition of the Camel. A handful of other Perl luminaries worked there at the same time (Jon Orwant, Nat Torkington).
When I joined in 2002, there were only a couple of developers in general, and no one sponsored to work on or evangelize any specific technology full time. Sometimes I wonder if Sun had more paid people working on Tcl.
I don't mean to malign or sideline the work anyone at ORA or ActiveState did in those days. Certainly the latter did more work to make Perl a first-class language on Windows than anyone. Yet that's very different from a funded Python Software Foundation or Sun supporting Java or the entire web browser industry funding JavaScript or....
Thanks for detailed reply. Yes, the marketing budget for Java was unmatched, but to my eye they were in retreat towards the Enterprise datacentre by 2001. I don't think the Python foundation had launched until 2001. Amazon was migrating off Perl and Oracle. JavaScript only got interesting after Google maps/Wave I think, arguably the second browser wars start when Apple launches Safari, late 2002.
So, I guess the counterfactual line of enquiry ought to be why Perl didn't, or couldn't, or didn't want, to pivot towards stronger commercial backing, sooner.
Python 3 couldn't even kill Python 2!
> Python 3 almost killed Python.
People were being crybabies; the critics were extremely vocal and few. Python 3 improved the language in every way and the tooling to upgrade remains unmatched.
Python 3 was a disaster and enterprises were still undertaking pointless 2->3 upgrade projects 10 years later
A month ago I had to fix a small bug in Python 2.6 code in one of internal systems. It won't be ever migrated, no capacity and no value
It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode.
Organizations struggled with it but they struggle with basically every breaking change. I was on the tooling team that helped an organization handle the transition of about 5 million lines of data science code from python 2.7 to 3.2. We also had to handle other breaking changes like airflow upgrades, spark 2->3, intel->amd->graviton.
At that scale all those changes are a big deal. Heck even the pickle protocol change in Python 3.8 was a big deal for us. I wouldn't characterize the python 2->3 transition as a significantly bigger deal than some of the others. In many ways it was easier because so much hay was made about it there was a lot of knowledge and tooling.
> It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode.
They should've just used Python 2's strings as UTF-8. No need to break every existing program, just deprecate and discourage the old Python Unicode type. The new Unicode type (Python 3's string) is a complicated mess, and anyone who thinks it is simple and clean isn't aware of what's going on under the hood.
Having your strings be a simple array of bytes, which might be UTF-8 or WTF-8, seems to be working out pretty well for Go.
I can't say i've ever thought "wow I wish I had to use go's unicode approach". The bytes/str split is the cleanest approach of any runtime I've seen.
What you propose would have, among other things, broken the well established expectation of random access for strings, including for slicing, while leaving behind unclear semantics about what encoding was used. (If you read in data in a different encoding and aren't forced to do something about it before passing it to a system that expects UTF-8, that's a recipe for disaster.) It would also leave unclear semantics for cases where the underlying bytes aren't valid UTF-8 data (do you just fail on every operation? Fail on the ones that happen to encounter the invalid bytes?), which in turn is also problematic for command-line arguments.
With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade.
Imagine if the same interpreter supported both Python 3 and Python 2. Python 3 code could import a Python 2 module, or vice versa. Codebases could migrate somewhat more incrementally. Python 2 code's idea of a "string" would be bytes, and python 3's idea of a "string" would be unicode, but both can speak the other's language, they just have different names for things, so you can migrate.
That split between bytes and unicode made better code. Bytes are what you get from the network. Is it a PNG? A paragraph of text? Who knows! But in Python 2, you treated them both as the same thing: a series of bytes.
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.
That distinction is indeed critical, and I'm not suggesting removing that distinction. My point is that you could give all those types names, and manage the transition by having Python 3 change the defaults (e.g. that a string is unicode).
I’m a little confused. That’s basically with Python 3 did, right? In py2, “foo” is a string of bytes, and u”foo” is Unicode. In py3, both are Unicode, and bytes() is a string of bytes.
The difference is that the two don't interoperate. You can't import a Python 3 module from Python 2 or vice versa; you have to use completely separate interpreters to run them.
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.
Ok who would suggest this when the community could take a modicum of responsibility
Why would I ever risk inflicting a stack trace like
on a user of Python 3.x where it isn't possible? (Note the UnicodeDecodeError coming from an attempt to encode.)> With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade.
Not without enormous and unnecessary pain.
It would absolutely have been harder. But the pain of going that path might potentially have been less than the pain of the Python 2 to Python 3 transition. Or, possibly, it wouldn't have been; I'm not claiming the tradeoff is obvious even in hindsight here.
I think you have causation reversed: it would have been at least two orders of magnitude greater to act like moving to python 3 was harder than staying. But you do you boo :emoji-kissey-face:
Pain on whose part? There was certainly pain porting all the code that had to be ported to Python 3 so that the Python developers could have an easier time.
Yes, exactly. customers need to stop acting like a bitch if they wanna be taken seriously
It was not a disaster in any way. People just complained about having to do something to upgrade their codebases.
Except that Python took the other path when migrating from Python 1 to Python 2 and ... guess what? That was a "disaster" too.
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.
Differences of scale do make a qualitative difference and must be considered when doing a migration.
The real problem here was releasing 3.0 as if it was stable, when the real usable version was 3.3/3.4
I recall 3.2 being okay. But it was definitely better by 3.4.
My problem with PERL was always that there's just too many things to remember, particularly if the code I'm debugging was written by someone who knows the language well. I'd be on a PERL project for awhile, then get pulled off to do Java or Ruby or whatever. By the time I needed to do PERL again, I had to go back and relearn everything. I never had that problem with Java, Ruby, Python, or Javascript.
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.
I don't know, but for me Perl has not died at all. I still use it for smallish scripts and some CGI. Maybe I am an old retired fart, but it is the tool I reach for, when the problem looks like Perl-ish. Like I reach for C or other languages when I need that kind of things.
agreed. it's often in my toolbox -- mostly since I already know it, and I prefer semi-colon-driven syntax -- but it's just one of a few languages I use.
By a lot of metrics it was a pretty awful language; hard to read, implicit, inconsistent, uncomfortable to write due to all the special characters etc. The idea of default arguments alone should have killed it by being a monumentally bad idea.
In my recollection perl6 helped kill it by making perl5 stagnate, but hopefully it would have died regardless.
I remember the first time a saw Perl, it looked like some kind of alien language from outer space, all the symbols it used looked insane.
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 ~~
“Warning: Smartmatch is experimental at foobar.pl line 42.”
If only I had a dollar for every time I’ve seen this message.
> I wrote a lot of Perl in the mid 90s and subsequently worked on some of the most trafficked sites on the web in mod_perl in the early 2000s, so I have some thoughts.
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.
Perl being so old means it's extremely fast for what it's designed to do, process streams or pipes. In a few tasks, it's faster than C, but being much faster to create a script or program that is useful, and with the implicit syntactic sugar, and since it's so flexible, you can just do things in the one way you know how and that's usually good enough.
Python is pretty good too for this and because modern computers are so fast it doesn't matter that it's much slower than perl, but if you're doing something like processing terabytes of files, it's probably worth your time to find or vibe code a one-liner in perl and torture it into working for your task.
Perl is amazing when it comes to regular expressions too. It's one of the reasons why perl is way more fun to write than Python. I still use perl for regex heavy tasks. I wish that python had integrated regex into the language the same way.
My fingers have long forgotten all the PERL they once knew. But it was always pleasant.
Perl's decline was cultural in the same way VMS's decline was. A fantastic approach and ecosystem—just one overtaken by a world that was moving on to a different set of desires and values.
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.
VMS decline was bound to a failing hardware business and company. That's a very different thing. Unix was around in the 80s and VMS did fine, its when DEC hardware business went down the tubes VMS lost out big time.
I don't understand how Perl fell off and PHP didn't
I think PHP is way more accessible syntactically, even with all the standard complaints about the language. In the early 2000s it felt like "simple C style function calls embedded in HTML templates" more or less. Not much to have to teach there.
And serving it tends to be "copy the files to your web server's public dir".
mod_php was dramatically simpler to use than mod_perl. If the sysadmin set it up, you didn't need to know it was there, and your regular PHP just ran really fast. That and nothing else really copied the "scriptable HTML file" paradigm which some people really really liked and made a very low barrier to entry compared to Perl. That's really what kicked off the demise of Perl -- it stopped being the most accessible way onto the internet. PHP also didn't screw up their major language upgrades like Perl did.
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.
I think this is the answer. PHP stayed relevant for so long because deployment was simple and the per-page-load performance hit was reasonably low.
Perl is a very difficult language. PHP was a comparatively simple language. PHP was just a scripting language for C and incorporated as many open source C libraries as possible back when open source libraries were a bit of disjointed mess.
PHP's success and Perl's decline was obvious at the time.
PHP is, at least for me, way, way more readable. Similar enough to Java that you don't have to re-learn syntax too much.
PHP has fallen off. Who is doing anything new in PHP?
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.
As someone who doesn't really know neither Perl nor PHP, PHP is more of a domain-specific EDSL than a mainstream programming language.
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.
At first glance it looks like shit. That's all the reason I need to never touch it.
It doesn't feel like I've missed out.
Perl died for many reasons. For me, it was a language that was always too tempting to be too clever by half. I'd been using Perl pretty significantly from 1995-2000 (perl4 to perl5) when I was introduced to Python (1.5.2)[^1]. I greatly appreciated its simplicity, zen, batteries included standard lib, and REPL. I found add on packages easier to install than dealing with CPAN. I switched to Python and basically never looked back.
[^1]: https://news.ycombinator.com/item?id=44790671
I had an interesting experience starting a job at ZipRecruiter, and finding that up to that point (2022), most of their code had been written in Perl. Their CTO had just gotten fed up with Perl and decreed that from now on, all new projects should be written in Go. I was the first one on my team to write code in Go.
There were various greybeards who kept telling me that Perl was a perfectly fine language and was fast enough for most purposes. I didn't argue with them and just backed away slowly.
Regarding Perl as a language, it seemed fine in the 1990s as a slightly more advanced alternative to Unix shells. But for me, what made it a failure as a language is that in order to have an array of hashes, or a hash of arrays, you needed to use references. That may have been a nice hack to enable some things in the 1990s, but even in 2005 that sounds pretty primitive and outdated to me. Plus the reliance on using magical variables consisting of $ and every non-letter ASCII character for all kinds of random stuff, like $_ and $# and so on. That may have been cool in 1992, but it's not 1992 any more.
Overall, Perl was pretty neat for little scripts up to 20 lines, but a bad idea for building an entire company on (like ZipRecruiter.) That's more of an indictment of ZipRecruiter than Perl.
Perl was super for little scripts hence it became popular. I think the killer feature was its fantastic regular expression language which beat everything at the time. All other languages had to do to was neutralise that one advantage and they did.
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.
25 years ago Perl allowed you to express what was in your head 10x more concisely as in other mainstream language (which have since caught up with some of the features).
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'm really, really confused by the typescript overtaking python comment, they're not really tackling the same domain of problems, right?
I thought it was really perceptive. Look at what JS was designed to do cf. what it's actually doing these days.
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.
I have experienced the decline in interest in Perl firsthand - having teached a class in Practical Perl Programming for 10 years at a local major university. First years saw 270ppl, second 150, then 100, 80, 50, and I think the last issue was 12 people.
I can speculate a lot about what killed Perl, or at least what called the schism, and in general what was the cause of the schism had roots in what Perl failed to innovate on. The cultural stuff was a side-effect of it.
But then also - Perl has huuuge impact on so many other languages, including JavaScript, that its place in the hall of fame cannot ever be disputed.
Should the Rust community take a lesson here, and maybe the Zig community to an extent?
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.
Agreed. The Rust community is an incredibly toxic place because they are so determined to involve politics in tech. I love the language, but I stay as far away from the community as I possibly can.
Oh man, here we go again. I see way more people complaining about the supposedly toxic Rust community than actual toxic Rust fans...
I'd love for politics to not infiltrate most aspects of life. Until everyone is able to, at least in part, persue life without being oppressed because of their immutable attributes, their belief or lack of belief system, who they choose to love and/or how they view themselves I think it's our civic duty to crusade for those causes.
> I think it's our civic duty to crusade for those causes
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?
There is zero way you don't alienate anyone. Ask women software engineers if they ever feel alienated. That's the reason why some communities like the python community do outreach for minorities in tech.
I'm a white man, and I have never felt "alienated" in so-called progressive spaces.
> outreach for minorities in tech
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.
> 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.
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.
> There's ALWAYS another place you can do something. Always. Where you draw the line is arbitrary.
Yes, that's the point. If you're drawing a line that agentively impacts others, you are the one responsible for defending where it's drawn.
> There's no rulebook anywhere saying we can't do this in tech.
Nobody is telling you that you can't do these things (except where impermissible by law). They are telling you not to rope or pressure unwilling others into it.
I think where we disagree is the "roping people in" thing.
If you're part of an organization, you're gonna be roped into their organization standards. Whether that be for behavior (no cursing on their forums), or for outreach, or whatever.
Joining the organization is optional, and if you feel, say, the python foundation doesn't align with your own beliefs, then just don't join. That's always been allowed.
As for working with people you might not want to, that's also just a part of organizations.
> Ask women software engineers if they ever feel alienated.
I have, on multiple occasions. The general summary of what I have learned from doing so, is that they find it cringe to ask, and appear annoyed by the suspicion that they're getting roped into someone else's political battle.
> That's the reason why some communities like the python community do outreach for minorities in tech.
No, they do it because it aligns with the cultural values of the people in charge. (As it happens, it also aligned with GvR's values when he was in charge.)
> I'm a white man, and I have never felt "alienated" in so-called progressive spaces.
... You don't feel alienated when people in your vicinity openly use pejorative language to refer to groups that you belong to (and don't have a choice about), or decry politicians or even pundits that dare to validate your grievances as extremists? You don't feel alienated when it's proposed that your grievances are inherently invalid because of that group belonging? You don't feel alienated by being repeatedly told that said group belonging makes you inherently incapable of "empathy" for various others, even as that same "empathy" is demanded of you? You don't feel alienated by the cultural assumption that a desire for more progressive income taxation, or cleaner energy, dictates a raft of social policies? You don't feel alienated by the entire body of in-group jargon that associates your group membership with negative qualities, or the opposition to language unilaterally deemed to reflect your "privilege" regardless of actual etymology?
If you haven't experienced these things, please let me know where to find the "progressive spaces" you frequent. I don't think I've seen one since at least OWS.
But don't you know, as OP said, Perl are reactionaries. Rust is progressive, and that's good!
[flagged]
I thought its decline was due to Perl's confusing syntax. That's what caused me to move away from it anyway.
Way back, Perl got off the ground really because, in contrast to the C compilers of the era, code written on one Unix ran on the others, usually unmodified. In my first jobs, where we had heterogeneous mixes of commercial Unixes, this was unbeatable. It also wrote like higher level shell, which made it easy to learn for systems people, who really were the only ones that cared about running things on multiple platforms most of the time anyway.
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.
Nobody will agree with this hot take, but I was around in the perl years, so maybe take this opinion with a grain of salt:
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.
There were programming envs that were easy to pick up in contemporary times. Hypercard is one that's often especially-fondly referenced as a non-traditional-programmer friendly example. Basic was much less arcane syntax-wise too. It's been a LONG time since I used Pascal but I also remember it being simpler to pick up.
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.
My client uses IBM servers with it’s hobbled version of Unix (AIX). Perl and access to copilot have really helped me out. I don’t love Perl but I’m damn glad I have acres to it.
I always thought of Perl as write friendly... And Ruby as Perl++.
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.
This theory may only sound convincing if you ignore parts of history which don't fit. Which is pretty much all of them. RTFM-culture was the norm for all online computer-related communities until 00s. Nothing of this phenomenon is Perl-specific.
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 Perl programmers as being weird but nice enough. It's Lisp programmers who were impossible to talk to and mostly responded to any questions by telling you to kill yourself.
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.
early pearl was just about having an awesome tool at your disposal. There was minimal code written in a team environment.
People were still amazed that you could do X in 1 line rather than 100 lines. Some people couldn't have done those 100 lines.
So the idea of recipes/spells/hacks was an intentional parallel.
It became a cultural thing. New people wanted to be respected for compact code that impressed people the same way they were impressed.
No mention of taint mode, you had to untaint all data coming from user. By comparing to fixed string or convert to number or filter through regexp at least. If this were more broadly adopted, would save everyone so many headaches.
The reason I mostly use Python is `python3 -mvenv env`. If I know that everything I might want is part of Perl's built-in modules, I prefer Perl.
Psst: even if you aren't using uv, you can use a global pip with `--python` and create your venvs `--without-pip` to save time (unless you have many invocations per venv, since `--python` works through a not-very-sane hack and is a bit slower as a result). And you can use Pipx to provision that global pip, and then you also have Pipx available. https://zahlman.github.io/posts/2025/01/07/python-packaging-...
> Any requirements for more modern application patterns that are emerging in the broader web development environment, like idk.... asynchronous I/O,
A good article, but there is nothing new about asynchronous I/O
This is a good article, but Golly, that was a faux pas!
There is no doubt that a product’s community culture and the maintainer’s attitude have a significant influence.
However, I used Perl and stopped using it without knowing anything about its internal politics or community. PHP, ASP, Java JSP and later Rails were much better than Perl for web development.
* I know that for some the mention of JSP will be rare, as it was ugly… However in the 2000s it was the state of the art
While I don't code in perl myself, one modern tool I use a lot is written in perl: https://github.com/digint/btrbk
This tracks. My own experience was that I moved from Perl to Python (for system and API stuff) and PHP (for templating and HTML).
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)
Perl was the duct tape of the Internet.
Regardless of the culture issues, it was effective!
Perl is still required for compiling autotools, openssl, nasm, etc.
As such, is likely to be around for a long, long time
Python is sometimes required for compiling software, too, but projects like the ones mentioned above requiring Perl have not switched to Python
I never really warmed to perl in its era but perl dbi was kind of perfect in its way. If you needed what it could do, it got very intuitive very fast, and was pretty terse. Both of which were supposedly the appeal of perl.
Nah Perl just wasn't a very good language. Not every language is equally good.
Neither is Ruby that has also similarly disappeared and article praised it? Or Lisp? On the opposite end, C, PHP, JS that are omni-present are good languages? Sometimes meritocracy and success don't align.
[flagged]
Ironically alluding to the possibility of others who would castigate you for saying something reasonable things, is not any less obnoxious than the castigation.
We don't have to say such things, because the syntactic sirup of ipecac and sputtering line noise of perl code speaks for itself.
Clearly not loudly enough - look at all the people here searching for some mysterious cultural reason it failed.
Perl 5's non-breaking conservatism kept old scripts running forever, but it also meant there was never a clear migration path the way Python 3 eventually provided, and that made long term planning a lot harder.
Perl did have `use strict`, so there was at least some plausible path to making non-breaking changes under a new pragma.
The OP’s theory that Perl 6’s radicalism allowed Perl 5 to be conservative sounds right to me.
Though at the same time the bit where `use strict` was optional wound up being off-putting to a lot of us, at least in part because we'd always wind up with _something_ that wasn't designed for `use strict` and had, uh, interesting failure modes.
It's the same drive that we see from JS to TS these days, or adding type hints to Python, and even to some extent why people pick up Rust: because you get a refusal to act and an explanation rather than wonky results when you goof.
IME there's been a wider shift away from worse-is-better, and Perl was kind of one of the early casualties of that. Part of that is also how science has marched on: When Python and Perl were new, the most popular typed languages were kind of tedious but not what people would consider _good_ at types these days. Perl was the first language I learned, and if I was transported back to the 1990s, I'd probably still pick it, even if I don't use it in 2025.
(OK, maybe I'd go all in on OCaml. Any way the camel wins.)
Perl's "decline" means there is some metric to measure how high Perl is. It was higher, but now it is lower. I don't think the metric is well-defined, though.
Perl shaped so much of early web culture. It’s interesting how a language can fade not because of capability, but because the community’s momentum shifted elsewhere.
I didn't like cpan and python was just easier and available, if python didn't exist I'd like to think I'd have invested heavily in perl because it was everywhere at some point.
I always thought Perl faded because it's write only and more readable alternatives showed up.
Why did it have to take over the world anyway?
> 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).
Well that's not what I meant. Does everything has to have taking over the world as a goal? Perl still exists, I guess it's updated, why isn't that enough?
> Does everything has to have taking over the world as a goal? Perl still exists, I guess it's updated, why isn't that enough?
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.
> I never got the impression that perl's goal was to take over the world
Yeah, it's more like the article is implying that should be the goal.
Yes: in retrospect, the Perl community (and maybe even the language in general) was cringe-worthy and perhaps even toxic.
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.
> Perl always had a significant amount of what you might call "BOFH" culture, which came from its old UNIX sysadmin roots. All of those passive aggressive idioms and in jokes like "RTFM", "lusers", "wizards", "asking for help the wrong way" etc.
> [...]
> Cultural conservatism as a first principle.
Counterpoint to this: Rust. Rust has a similar RTFM/"wizards" culture, but is not culturally conservative (in any sense of the word).
My two cents: Perl's "culture" had little to do with its fall. I think Perl's problems run much deeper. Perl is built on rotten foundations. It's fundamentally a scripting language (albeit with bolted on additions to make it kinda-OOP), and it therefore has all the problems that scripting languages have for building large software projects.
Those problems have no quick fix, and indeed fixing them would require throwing the language out entirely -- at which point, why not simply switch to another language entirely (which is exactly what happened...).
Probably stretching the cultural metaphor too far here, but Rust has much more of a “vanguard of the proletariat” vibe & appears susceptible to some of the problems inherent in that political mission.
I looked at Perl once and decided to just not use it, and hoped it'd go away so I never have to use it. Sorry, the decline was probably due to it being bad.
Perl was aimed at intelligent people that considered obfuscated code challenges a sport and had a tendency for masochism.
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.
Related:
What Killed Perl?
https://news.ycombinator.com/item?id=45977900
Or was it that Perl is a write only language and readability is maintainability?
Perl was a bad language, line noise. It was better than using bash and awk for complex scripting, and better than using C for CGI pages. But Python and PHP were better and more readable for those use cases, and killed Perl.
Python is mentioned and I think the key reason it's continued to grow while Perl declined, is a vastly more welcoming culture.
Python says you know nothing, but want to automate a small task. The community will help you. More so than any other language.
Then again, Python 2 and Python 3 are two different languages.
Very few projects are willing to have such a massive migration.
"Willing" is an interesting word choice. There was quite a bit of resistance in the Python world despite the clear benefits. (2.x really could not be fixed, because the semantics were fundamentally broken in many places.)
It's open source.
Any one ( and I'm sure a few have tried) can fork 2.x and keep using it.
3.x is remarkably easy , you can probably onboard a non programer to Python in a month.
> Any one ( and I'm sure a few have tried) can fork 2.x and keep using it.
They have tried and succeeded: https://docs.activestate.com/activepython/2.7/
I still consider the result "broken".
Is anyone programming in Rakudo/Perl6?
Technically, no. As Rakudo is not a programming language, and Perl6 is a deadname.
But there are indeed plenty of people doing projects with the Raku Programming Language.
Plenty of people then. Okay! I meant Raku, yes.
perl died because "Perl is write once, read never"
Executable line noise.
I worked for a few years in an large org which utilized perl for build scripts, testing automation, and a few other things. I would summarize the half decade Perl learning curve as initial bewilderment, intermediate cult like praise, to advance level disillusionment.
There was something about scaling usage in large teams that felt awkward and high friction.
I dunno, I interacted with perl about 2000-2003 in a small way, it always seemed pretty friendly and welcoming, I loved perlmonks and remember it happily.
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.
C'mon. The language was like something born in Hogwart's. Magic spells, incantations. It lost because it was not an easy language to learn - and others were (in particular Python) - while being just as powerful.
Oh Perl, the programming language entirely made of footguns. Is it dead already?
Perl failed because it's a write-only language. The only time you really understand a Perl program is when you're writing it. Check back in six months and good luck. It's like trying to read someone else's regular expression - and the connection between Perl and Regular Expressions is not accidental.
I don't get why Ruby is mentioned before PHP. The only Ruby thing I've ever come across is GitLab, and not with positive associations either - up until maybe 3, 4 years ago particularly Sidekiq was a constant point of utter pain.
I suspect it's because Ruby's ability to deal with strings is so heavily influenced by Perl.
When I first started using Ruby after years of Perl, it felt familiar but everything was just more... sensible.
I was surprised by that, too, and assumed it was a decade-old article until I saw the date at the bottom. Both being mentioned before Python is wilder, as is the total exclusion of JavaScript.
JavaScript on the backend is a rare thing to see, even in "resume driven development" scenarios it's usually some sort of static build that gets pushed to S3 or whatever.
Are you time traveling from 1998, when AOL acquired Netscape and sidelined Livewire?
Node.js is the most popular web framework/technology in the StackOverflow developer survey. Express is more popular than FastAPI, Django, Flask and Rails in the same survey. Just... what are you talking about?
[dead]
i disagree, python is Just Better. ive never used perl but ive had to install it due to some antique tools requiring it, and every time its been an incomprehensible mess. i still have no idea how packages work in perl. also, it seems like everything in perl is a string? and the syntax looks like a mess.
maybe its painful for guys to admit that languages could be a lot better designed, and when such langauges appeared, everyone flocked to them.
> also, it seems like everything in perl is a string?
It's actually somehow even worse than this. The Perl type system is honestly ridiculous. Most veteran Perl developers don't fully understand it.
https://blogs.perl.org/users/leon_timmermans/2025/02/a-deep-... is a good introduction.
The number of blogs posted on here by people who can’t be arsed to make their writing legible on mobile blows my mind. Did everybody just skip the section of their CSS journey that covered media queries or what?
I enjoyed the article but it was a nightmare to read on my phone’s browser
(Author) Sorry you had a poor experience, yes my blog "engine" is a hacked together POS that barely works, with hand written CSS, that was mostly built before the mobile first era, I have just tweaked it to work somewhat on portrait phone screens, but it's really not a very good website. I do try to generate fairly plain semantic HTML so the pages should work pretty well with "reader mode" or user stylesheets if you have access to that. That's probably the optimal experience.
I definitely should have just opened it in reader mode in Safari but I just told myself I’d just not lose my spot again several times like a dope
Fine for me on iPhone Safari.