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.

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.

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.

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.

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.

>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.

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!

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)

I only recently learned about this, maybe a month ago. It made a lot of sense to me.

> 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.

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.

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.

>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.

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'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.

> 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.

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.

But I can look at most Python code and be able to understand what it does. With perl, I have to look up so much.

- Why is there a `1;` on a single line in the middle of this file?

- What is `$_`?

- This parallel execution manager doesn't actually seem to define what code needs to run in parallel in any specific way, how does this work?

- What is this BEGIN block at the start of this Perl file? Why is that necessary?

- What's going on with qx, qw, qq?

- What does chomp do when it's just on its own line, with no arguments given to it?

Again: python syntax is more akin to what you are used to, and so it feels more comfortable to you.

$_ is inscrutable if you haven't studied perl, but the same thing would happen to anyone who sees a python decorator for the first time. what does "else: do after a while loop in python? Only people who know python know what it does (and I suspect most don't). The different quoting operators are also trivial to learn. In comparison, yield from python is also simple syntax but the semantics are much more involved.

BEGIN? Take 60 seconds to read what it means. And if you knew awk, you'd not have to do that, as it was directly lifted from awk.

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.

> 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:

    preloop:
      if condition:
        do_more_stuff()
        goto preloop

    while condition:
      do_more_stuff()

and these are also equivalent:

    preloop:
      if condition:
        do_more_stuff()
        goto preloop
      else:
        wrap_it_ip()

    while condition:
      do_more_stuff()
    else:
      wrap_it_up()

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.

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'.

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.

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.

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.

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.

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.

>>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.

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).

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 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.

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.

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.

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.

The point is not that such quirks are impossible to learn; the point is that they make the language extremely unpleasant to use.

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.

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

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.

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 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.

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.

I don't think "Pythonista" was a thing in the 2000s. Python is very old and only became more of a "fad" relatively recently.

It was definitely a thing.

> 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.

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.

First time I read something like that about Perl. Is this personal experience during the Perl peak period or extrapolation from phrases

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

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

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.")

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.

(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.

> 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.

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.

> 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.

I need to hear more about this Software Local 2142.

In fairness, Perl died because it was just not a good language compared to others that popped up after its peak. Sometimes people just move to the better option.

Perl is a great language, the way Scala and Haskell are great: as openly experimental languages, they tried interesting, unorthodox approaches, with varied success. "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say.

Perl is not that good a language though for practical purposes. The same way, a breadboard contraption is not what you want to ship as your hardware product, but without it, and the mistakes made and addressed while tinkering with it, the sleek consumer-grade PCB won't be possible to design.

> "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say.

Perl lets every developer write Perl in their own idiosyncratic way.

And every developer does.

It makes for very un-fun times when I'm having to read a file that's been authored by ten developers over ten years, each of whom with varying opinions and skill levels.

I guess in 2026, it'll be 11 developers writing it over 11 years. My sincere apologies to those who come after me, and my sincere fuck-you to those who came before me. :)

Something I only figured out in the ‘10s is that the main tax of code smells is during debugging. Debugging when taken to the level of art is less about sorting all of the possible causes for a problem by likelihood but by ease of validation.

Things that are cheap to check should be checked first unless they are really unlikely. You change the numbers game from trying to make the biggest cleaving lines possible, to smaller bites that can be done rapidly (and perhaps more importantly, mentally cheaply).

Code smells chum the waters. Because where there is smoke sometimes there is fire, and code smells often hide bugs. You get into Tony Hoare’s Turing award speech; either no bugs are obvious, or there are no obvious bugs.

So I end up making the change easy and then making the easy change because we have more code each week so the existing code needs to be simpler if someone is going to continue to understand the entire thing.

Perl doesn’t seem to have figured this out at all.

Exactly. Perl is about experimenting, trying things your way, and discovering new and good ways to write programs. Which is a wonderful capability for research and discovery, and for art or recreation, but not that great for industrial production.

This is why Perl was quite fit for the job at the dawn, or, rather, the detonation phase of the Internet explosion in late 1980s and early 1990s, along with Lisp and Smalltalk that promote similar DIY wizardry values. But once the industry actually appeared and started to mature, more teamwork-friendly languages like Java, PHP, and Python started to take over.

> in 2026, it'll be 11 developers writing it over 11 years.

Perhaps too, a tool that's been around and in active maintenance for 11 years has been wildly successful.

I wouldn't say "wildly". I would say that it's critical enough to the company's workings that they devote enough resources to it to keep it going, but not enough resources to consider re-writing it or re-factoring it to be easier to work on.

It could have used a good "Perl: the Good Parts" book.

With a team where everybody wrote it in a similar style, Perl did perfectly well. Mod_perl was fast. I liked Perl.

Then Django came out, and then Numpy, and Perl lost. But Python is still so incredibly slow....

Check out "Perl Best Practices" by Damien Conway, and the more recent "Modern Perl" by Chromatic. Both can be had as paperbacks, and I think both are also available free on online.

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.

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 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.

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.

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.

Reasoning through analogies?

Not really. It wasn’t audacious in service of anything innovative. Haskell takes functional programming to the nth degree, scala tried to be an advanced Java for example better at concurrency.

Perl was an early dynamic (garbage collected) “scripting language” but no more advanced than its contemporary python in this regard.

It had the weird sigils due to a poor design choice.

It had the many global cryptic variables and implicit variables due to a poor design choice.

It has the weird use of explicit references because of the bad design choice to flatten lists within lists to one giant list.

It actually was the one thing you said it wasn’t - a good practical general language at least within web and sysadmin worlds. At least until better competitors came along and built up library ecosystems.

There was so much complexity hidden behind "do what I mean". For example, scalar vs array context which was super subtle:

  my @var = @array  # copy the array
  my $var = @array  # return the count of elements in array

Or even worse:

  my($f) = `fortune`; # assigns first line of output to $f.
  my $f = `fortune`; # assign all output to $f.

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:

    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.

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 funny, because something like

    array var = array  # copied
    int var = array    # length

or

    var = array  # copied
    var = array.to_i  # length

is less subtle to me but I can't put my finger on why.

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.

I always found contextual eval interesting. It's a generalized version of toString in a way

It's not complexity, it's magic. Useful when one cannot be bothered to write array.length. So is if (@a) when the array is empty.

> 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.

Yeah I think I would have been considered part of the “in” crowd of Perl to some degree and it wasn’t the culture that drove me away and to Python.

It was Django and the people involved with it.

> and the people involved with it.

Culture?

I agree and Steve Yegge covered the reasons well here: https://sites.google.com/site/steveyegge2/ancient-languages-...

His point about references is no small thing. Other dynamic languages don’t make users think much about the distinction between references and values at the syntax level. With Perl you needed to use “->” arrow operator frequently if and only if you were using references. So getting at a map inside an array or vice versa had its own syntax vs reading a string in a map or array.

Also it had bolted on, awkward OO on top of the bolted on, awkward params passing. You literally had to shift “self” (or “this”) off a magical array variable (@_).

By default it wouldn’t warn if you tried to read from an undeclared variable or tried to use one in a conditional or assign from one. You had to declare “use strict;” for that. Which wasn’t hard! But these awkward things piled up, a bunch of small cuts. Don’t forget “use warnings;” also, another thing to put at the top of every Perl file.

To the extent its awkward syntax came out of aping of shell and common Unix cli tools, you could maybe see it as cultural issue if you squint.

But any language in the mid 90s was infected with the “rtfm” priesthood vibe the author writes about, because the internet then was disproportionately populated by those sysop types, especially the part that can answer programming language questions on usenet, which is basically where you had to ask back then.

So for example Rails won for technical reasons, it is much more concise with fewer footguns than its Perl equivalents. I was actively coding web stuff in Perl when it came along and early switched. It wasn’t a cultural thing, having choice in Perl was fine (and ruby has sadly never grown much culture outside Rails - it could really use some). It probably did help that it came along in the mid aughts by which time you could ask questions on the web instead of Usenet. And it used YouTube for that first rails demo. So ruby did end up with a less sysopy culture but that had more to do with the timing of its success than the success itself.

> bolted on, awkward params passing

Shell had to do this because of shell reasons, like how you need spaces where you shouldn't. Perl post-dated C by over a decade, so there was no reason for goofy argument unpacking.

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 (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.

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.

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.

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)

While I don't code in perl myself, one modern tool I use a lot is written in perl: https://github.com/digint/btrbk

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.

> if difficulty itself becomes a badge of honour, you've created a trap: anything that makes the system more approachable starts to feel like it's cheapening what you achieved. You become invested in preserving the barriers you overcame.

The mentality described here has always galled me. Half the reason I’m willing to scramble up these hills is to gain the perspective to look for an easier way up the next time. It’s my reward for slogging through, not for the gathering of sycophants.

I’m not sure you’ve mastered a thing until you’ve changed the recipe to make it a little bit better anyway. My favorite pumpkin pie recipe, isn’t. As written the order of operation creates clumps, which can only be cured with an electric mixer. You shouldn’t need an electric mixer to mix pumpkin pie filling. If you mix all the dry ingredients first, you get no clumps. And it’s too soupy. Needs jumbo eggs, not large. So that is my favorite recipe.

But maybe this is why I end up writing so many tools and so much documentation, instead of hoarding.

There was a lot of pressure in the Perl community to write things as succinctly as possible instead of as maintainably and understandably. That’s not realistic for use in a field with a lot of turnover and job hopping.

Yeah the joke was, Perl is write-only.

Write-only perhaps, but with perl you only have to write it once and it'll run forever, anywhere. No breaking on updates, no containers, no special version of Perl just for $application, just the system perl.

Because of this, in practice, the amount of system administration mantainence and care needed for perl programs is far, far less than other languages like python where you actually do have to go in and re-write it all the time due to dep hell and rapid changes/improvements to the language. For corporate application use cases these re-writes are happening anyway all the time so it doesn't matter. But for system administration it's a significant difference.

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 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.

> 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 EFnet/#perl which included most of the core development team. I don’t really have experience with the non-core social environment, sorry.

> [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?

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 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".

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 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.

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.

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...

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.

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.

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.

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 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 ~~

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".

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.

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.

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.

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.

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.

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

Sorry for this repetition, but how popular was/is monkeypatching in Perl?

Perl was the duct tape of the Internet.

Regardless of the culture issues, it was effective!

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.

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.

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 thought its decline was due to Perl's confusing syntax. That's what caused me to move away from it anyway.

Perl6/Raku killed Perl.

Python 3 almost killed Python.

It's normal. Once a community loses faith, it's hard to stop them from leaving.

I'd take this a step further and say that the design flaws that motivated Perl6 were what really killed Perl. Perl6 just accelerated the timeline.

I do imagine a saner migration could've been done - for example, declaring that regexes must not start with a non-escaped space and division must be surrounded by space, to fix one of the parsing problems - with the usual `use` incremental migration.

Agree 100%. We were told to wait for any improvements or new features we wanted and just to wait for Perl 6, which never came

Yep. Perl 6 was a wall that Perl 5 would never move beyond. It’s still Perl 5 25 years later.

Python 3 couldn't even kill Python 2!

Python 3 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.

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

> With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade.

Not without enormous and unnecessary pain.

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.

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:

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

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.

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.)

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 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.

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.

> 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.

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 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.

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.

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.

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.

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.

and people wonder why raku had so many things it needed to change to free the excellent core of the language and its ideas

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.

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.

Just fork Rust if you don't like any politics. Unfortunately, Rust might not be worth forking, for anyone.

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.

"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".

perl died because "Perl is write once, read never"

Executable line noise.

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 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.

Nah Perl just wasn't a very good language. Not every language is equally good.

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.

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.

Related:

What Killed Perl?

https://news.ycombinator.com/item?id=45977900

C'mon. The language was like something born in Hogwart's. Magic spells, incantations. It lost because it was not an easy language to learn - and others were (in particular Python) - while being just as powerful.

I don't get why Ruby is mentioned before PHP. The only Ruby thing I've ever come across is GitLab, and not with positive associations either - up until maybe 3, 4 years ago particularly Sidekiq was a constant point of utter pain.

I 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.

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?

Are you time traveling from 1998, when AOL acquired Netscape and sidelined Livewire?

i disagree, python is Just Better. ive never used perl but ive had to install it due to some antique tools requiring it, and every time its been an incomprehensible mess. i still have no idea how packages work in perl. also, it seems like everything in perl is a string? and the syntax looks like a mess.

maybe its painful for guys to admit that languages could be a lot better designed, and when such langauges appeared, everyone flocked to them.

> also, it seems like everything in perl is a string?

It's actually somehow even worse than this. The Perl type system is honestly ridiculous. Most veteran Perl developers don't fully understand it.

https://blogs.perl.org/users/leon_timmermans/2025/02/a-deep-... is a good introduction.

Perl's "decline" saved it from a fate worst than death: popularity and splitting into dozens of incompatible versions from added/removed features (like python). Instead Perl is just available everywhere in the same stable form. Scripts always can just use the system perl interpreter. And most of the time a script written in $currentyear can run just as well on a perl system interpreter from 2 decades ago (and vice versa). It is the perfect language for system adminstration and personal use. Even if it isn't for machine learning and those kinds of bleeding edge things that need constant major changes. There are trade-offs.

This kind of ubiquitous availablility (from early popularity) combined with the huge drop-off in popularity due to raku/etc, lead to a unique and very valuable situation unmatched by any other comparable language. Perl just works everywhere. No containers, no dep hell, no specific versions of the language needed. Perl is Perl and it does what it always has reliably.

I love it. The decline was a savior.

Perl's binary brings with it the ability to run every release of the language, from 5.8 onwards. You can mix and match Perl 5.30 code with 5.8 code with 5.20 code, whatever, just say "use v5.20.0;" at the start of each module or script.

By comparison, Python can barely go one version without both introducing new things and removing old things from the language, so anything written in Python is only safe for a a fragile, narrow window of versions, and anything written for it needs to keep being updated just to stay where it is.

Python interpreter: if you can tell "print" is being used as a keyword rather than a function call, in order to scold the programmer for doing that, you can equally just perform the function call.

> By comparison, Python can barely go one version without both introducing new things and removing old things from the language

Overwhelmingly, what gets removed is from the standard library, and it's extremely old stuff. As recently as 3.11 you could use `distutils` (the predecessor to Setuptools). And in 3.12 you could still use `pipes` (a predecessor to `subprocess` that nobody ever talked about even when `subprocess` was new; `subprocess` was viewed as directly replacing DIY with `os.system` and the `os.exec` family). And `sunau`. And `telnetlib`.

Can you show me a real-world package that was held back because the code needed a feature or semantics from the interpreter* of a 3.x Python version that was going EOL?

> Python interpreter: if you can tell "print" is being used as a keyword rather than a function call, in order to scold the programmer for doing that, you can equally just perform the function call.

No, that doesn't work because the statement form has radically different semantics. You'd need to keep the entire grammar for it (and decide what to do if someone tries to embed a "print statement" in a larger expression). Plus the function calls can usually be parsed as the statement form with entirely permissible parentheses, so you have to decide whether a file that uses the statement should switch everything over to the legacy parsing. Plus the function call affords syntax that doesn't work with the original statement form, so you have to decide whether to accept those as well, or else how to report the error. Plus in 2.7, surrounding parentheses are not redundant, and change the meaning:

  $ 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.

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.

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.

> 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.

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.