Perl's decline was cultural

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

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.

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

The term "surrogate activity" comes to mind, specifically, activities of no real value that some people like to waste time on to feel better about themselves.

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.

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

My anecdotal experience was with perl guys who were ex-military, irreverent, and fly-by-the-seat-of-your-pants. The Java and .NET guys were straight laced and nerdy.

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

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

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.

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

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

In a similar vein, as the industry matured, we went from having teams of wizards building products, to teams of "good-enough" developers, interchangeable, easy to onboard. Perl culture was too much about craft-mastery which ended up being at odds with most corporate cultures.

Unfortunately, as a former Perl dev, it makes a lot of other environments feel bland. Often more productive yes, but bland nonetheless. Of the newer languages, Nim does have that non-bland feel. Whether it ends up with significant adoption when Rust and Golang are well established is a different story.

The big pearl of wisdom I took from Larry Wall seemed to be counter to the culture I experienced looking in from the outside. That always confused me a bit about Perl.

And that was, paraphrased: make the way you want something to be used be the most concise way to use it and make the more obscure features be wordy.

This could have been the backbone of an entire community but they diminished it to code golf.

Couldn't they have figured out one decent way to do things before releasing features to all users? I tried Scala for a bit then decided it was complicated for no good reason.

Idk about Haskell, but I used Erlang which is also purely functional. No matter how long I used it and tried to appreciate its elegance, it became clear this isn't a convenient way to do things generally. But it was designed well, unlike Scala.

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.

Or even worse:

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

[^1]: "It's all about context" (2001): https://archive.ph/IB2kR (http://www.stonehenge.com/merlyn/UnixReview/col38.html)

That's not super subtle any more than it's super subtle that "*" performs multiplication and "+" performs addition. Sometimes you just need to learn the language.

This is not a general defense of Perl, which is many times absolutely unreadable, but this example is perfectly comprehensible if you actually are trying to write Perl and not superimpose some other language on it.*

What exactly is complex or "super subtle" about this? It's the textbook example from the 1st chapter in the tutorial or something?

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

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

> and the people involved with it.

Culture?

> bolted on, awkward params passing

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

> Perl was (and still is) a very expressive and concise language for working with text and a unix-style system. It exists in the odd space between a shell language and a general purpose language.

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.

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

There wasn't pressure to write concise code exactly, but if you posted your code somewhere the odds were good that somebody would reply with a way to do the same thing with less code, followed by someone else who managed to shave several lines/characters off of that, etc.

While almost all of the time it was all just people having fun (perl is fun and play was encouraged) and not an admonishment of the code you'd posted or an example of how it should have been written I can see how some folks might have gotten that impression. Especially if they were new to perl and were more used to languages where TIMTOWTDI wasn't thing

> There was no such pressure. That's ridiculous.

I lived it. I'm sure there's still some Mailing List archives and IRC snippets that still endure, demonstrating the utter vicious 1-upmanship of how to do something in Perl as succinctly as possible. Why do X and Y when you can just do Z? What are you really trying to do? etc.

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.