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.
Also, PERL allows you to write the most unmaintainable code I've ever seen. I ran across a single line of PERL that would read a buffer, do some simple data transformations, add framing information (some of it derived from the data like length, data type, and checksum), and then write out the completed buffer.
It was beautiful. And also completely unmaintainable. Even the guy who wrote it didn't remember how it worked and had to fiddle with it for twenty minutes before he remembered a variable he used was getting set as a side effect of something else later in the line. That's great for a programming contest, but not so much for production code you may be tasking a newly minted software developer with maintaining.
Granted, you can write maintainable PERL code. But over the years the PERL has been hands down the least maintainable in different jobs and projects.
Perl 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.
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".
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 ~~
It doesn't feel like I've missed out.
There were various greybeards who kept telling me that Perl was a perfectly fine language and was fast enough for most purposes. I didn't argue with them and just backed away slowly.
Regarding Perl as a language, it seemed fine in the 1990s as a slightly more advanced alternative to Unix shells. But for me, what made it a failure as a language is that in order to have an array of hashes, or a hash of arrays, you needed to use references. That may have been a nice hack to enable some things in the 1990s, but even in 2005 that sounds pretty primitive and outdated to me. Plus the reliance on using magical variables consisting of $ and every non-letter ASCII character for all kinds of random stuff, like $_ and $# and so on. That may have been cool in 1992, but it's not 1992 any more.
Overall, Perl was pretty neat for little scripts up to 20 lines, but a bad idea for building an entire company on (like ZipRecruiter.) That's more of an indictment of ZipRecruiter than Perl.
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
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
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.
The only thing I kept using Perl for over a decade was RADIUS (we ran Radiator, which was arguably the most insanely flexible AAA server for ISPs)
I enjoyed the article but it was a nightmare to read on my phone’s browser
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.
There was something about scaling usage in large teams that felt awkward and high friction.
What Killed Perl?
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!
Rubyists vs. Pythonistas isn't any better.
Programming languages as counter-cultural lifestyle choices is pretty "cringe" as the kids say.
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)
If Perl had had a good culture, then conserving it would have been good!
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
Python 3 almost killed Python.
It's normal. Once a community loses faith, it's hard to stop them from leaving.
To me it seems that some in the Rust community in particular, perhaps because they're just the most vocal, are tightly coupled to progressive, social activism.
I guess in general I just find myself wishing that political and social issues could be entirely left out of technical communities.
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
Python says you know nothing, but want to automate a small task. The community will help you. More so than any other language.
Then again, Python 2 and Python 3 are two different languages.
Very few projects are willing to have such a massive migration.
> [...]
> 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...).
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.
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')
man 3pm Errno
my $fh;
unless (open($fh, "<", "/fangorn/spouse")) {
if ($!{ENOENT}) {
warn "Get a wife!\n";
} else {
warn "This path is barred: $!";
}
}
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.
Once languages came along that did okay regexes and good hash tables along with getting other stuff decent, Perl just got pushed aside.
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.
And serving it tends to be "copy the files to your web server's public dir".
One of the few insights in the blog post that aren't stupid, fake, inconsistent and schizophrenic, is the one about PHP's common approach regarding spinning up new processes.
PHP's success and Perl's decline was obvious at the time.
Turns out it doesn't really matter what domain you were originally trying to tackle. If you've stumbled upon a low friction way of achieving other things, people are going to use your tool for those things, even if it's not the optimal tool for those domains.
I dread the JS/TS future, but it's obviously coming.
I do imagine a saner migration could've been done - for example, declaring that regexes must not start with a non-escaped space and division must be surrounded by space, to fix one of the parsing problems - with the usual `use` incremental migration.
People were being crybabies; the critics were extremely vocal and few. Python 3 improved the language in every way and the tooling to upgrade remains unmatched.
The OP’s theory that Perl 6’s radicalism allowed Perl 5 to be conservative sounds right to me.
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.
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.
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.
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.
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.
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.
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.
my @var = @array # copy the array
my $var = @array # return the count of elements in arrayIt was Django and the people involved with it.
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.
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)
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.
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.
There’s a whole lot of words popularly excised (as you just did) from that line of the Zen to create a false polar opposite to Perl’s TMTOWTDI that was never actually part of Python’s philosophy.
The actual line from the Zen of Python is: “There should be one—and preferably only one—obvious way to do it.” (omissions in italics).
Also, I think Larry Wall's "Diligence, Patience, Humility"[0] is among my favourite articles about programming.
[0] https://www.oreilly.com/openbook/opensources/book/larry.html
But those who remember the regulars of, say, efnet #perl (THIS ISN'T A HELP CHANNEL), there was a dearth of kindness for sure. I was probably part of it too, because that was the culture! This is where the wizards live, why are you here asking us questions?
Like cms, I'm also hesitant to name names, but the folks I'm thinking of were definitely perl-famous in their day.
There were also a bunch of great people in the community, and they helped me launch my career in tech in the 90s, and I have close internet friends from that community to this day (and great memories of some who have passed on). But there were definitely also jerks.
That made me laugh. Unlike actually working with Perl references, which made me want to cry.
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, however, a significant language. It has left a mark and influence on the culture and industry of programming. Nothing to sneeze at.
And that was, paraphrased: make the way you want something to be used be the most concise way to use it and make the more obscure features be wordy.
This could have been the backbone of an entire community but they diminished it to code golf.
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.
array var = array # copied
int var = array # length
var = array # copied
var = array.to_i # length
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.)
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?
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.
I never wanted to have to reason my way through chasing pointers through nested hashrefs again.
Technically you are allowed to use % like so: %{$hash1->{“hash2”}}. Which, just - lol.
This perl syntax caused some kind of rejection on almost physical level. It was same for many of my friends. "Zen of python" was a breath of fresh air.
as backend we had oracle. at first we tried oracle/linux (just released). but we never managed make it work (oracle engineers that came to us failed as well). So we got dedicated sun server for it.
One day I was bored, installed mysql on my workstation, made a changes in couple of queries and all of sudden i got x20 performance of sun box with oracle. Lead developer said that it's bad solution as mysql doesn't properly supports referential integrity (we didn't actually used it in oracle iirc)
Perl 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”.
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.
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. :)
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....
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.
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)
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.*
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.
Hopefully I am paraphrasing you correctly.
Things that are cheap to check should be checked first unless they are really unlikely. You change the numbers game from trying to make the biggest cleaving lines possible, to smaller bites that can be done rapidly (and perhaps more importantly, mentally cheaply).
Code smells chum the waters. Because where there is smoke sometimes there is fire, and code smells often hide bugs. You get into Tony Hoare’s Turing award speech; either no bugs are obvious, or there are no obvious bugs.
So I end up making the change easy and then making the easy change because we have more code each week so the existing code needs to be simpler if someone is going to continue to understand the entire thing.
Perl doesn’t seem to have figured this out at all.
This is why Perl was quite fit for the job at the dawn, or, rather, the detonation phase of the Internet explosion in late 1980s and early 1990s, along with Lisp and Smalltalk that promote similar DIY wizardry values. But once the industry actually appeared and started to mature, more teamwork-friendly languages like Java, PHP, and Python started to take over.
It's essentially complaining about using feature wrong on purpose, because the person that made mistake never learned the language.
my($var1, $var2...) is a way to multi-assign variables from an array.
and that makes perfect sense when you look at it. Perl have no multiple returns, but if you need a function that returns 2 variables it is very easy to make it work with:
my ($bandwidth, $latency) = speedtest($host)
my @lines = `fortune`
foreach my $line (`fortune`) {}
Now you might ask "why make such shortcuts?". Well, one of big mistakes when making Perl is that it was also aimed as replacement for sed/awk for the oneliners, so language is peppered with "clever short ways to do stuff", and it's a pleasure to use in quick ad-hoc oneliners for CLI.... but then people try to use same cleverness in the actual code and it ends up with the unreadable mess people know Perl for.
the fact you can do
my ($first_line, $second_line, ...) = `fortune`
you gave it array, and it just did what it does with arrays.
Even C gets it's fair share of flack for how it overloads * to mean three different things! (multiplication, pointer declaration, and dereference)
Culture?
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.
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.
> 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!"
- 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?
Pretending to be a all serius grown ups language is cringe.
Perhaps too, a tool that's been around and in active maintenance for 11 years has been wildly successful.
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.
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.
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.
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.
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
Perl and some of Perl's quirks will make more sense once you realise that it is deeply rooted in UNIX command line utilities, UNIX conventions and some UNIX shell defaults, except when it is not, i.e.
- What is `$_`?
- What is this BEGIN block at the start of this Perl file? Why is that necessary?
- What does chomp do when it's just on its own line, with no arguments given to it?
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.
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.
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...
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.
It certainly was the major factor in how I connected the dots!
Haven’t really thought about it until now, but I suppose having Larry Wall and Randal Schwartz telling you to RTFM guides your early development in a certain manner.
I certainly have never considered myself a developer or programmer though. I can pick up enough syntax to get a quick hack done or start a MVP to demo my ideas, but I leave the “big boy” dev stuff to the professionals who can run circles around me.
I wish bash was the thing that was dying. As an industry, we need to make better choices.
$_ 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.
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.
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.
There's been a flurry of discussion on Hacker News and other tech forums about what killed Perl. I wrote a lot of Perl in the mid 90s and subsequently worked on some of the most trafficked sites on the web in mod_perl in the early 2000s, so I have some thoughts. My take: it was mostly baked into the culture. Perl grew amongst a reactionary community with conservative values, which prevented it from evolving into a mature general purpose language ecosystem. Everything else filled the gap.
Something to keep in mind, is that although this is my personal take, and therefore entirely an opinion piece, I was there at the time. I stopped doing Perl properly when I left Amazon, I think this would have been around 2005. It's based on the first hand impressions of somebody who was very deeply involved in Perl in its heyday, and moved on. I have a lot of experience, from both inside and outside the tent.
What culture? 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. None of this is literally serious, but it does encode and inform social norms that are essentially tribal and introverted. There implicitly is a privileged population, with a cost of entry to join. Dues must be paid. Cultural conservatism as a first principle.
This stems from the old locked-down data centre command culture. When computer resource was expensive, centralised, fragile, and manually operated, it was rigidly maintained by gatekeepers, defending against inappropriate use. I started my career as an apprentice programmer at the very end of this era, (late 80s) pre-web, and before microcomputers had made much inroads, and this really was the prevailing view from inside the fort. (This is a drawback about fort-building. Once you live in a fort, it's slightly too easy to develop a siege mentality). Computers are special, users are inconvenient, disruption is the main enemy.
An unfortunate feedback loop in this kind of "perilous" environment is that it easily turns prideful. It's difficult to thrive here, if you survive and do well you are skilled; you've performed feats; you should mark your rites of passage. This can become a dangerous culture trap. If you're not careful about it, you may start to think of the hazards and difficulties, the "foot guns", as necessary features - they teach you those essential survival skills that mark you out. More unkindly, they keep the stupid folk out, and help preserve the high status of those who survived long enough to be assimilated. Uh-oh, now you've invented class politics.
The problem with this thinking is that it's self-reinforcing. Working hard to master system complexities was genuinely rewarding - you really were doing difficult things and doing them well. This is actually the same mechanism behind what eventually became known as 'meritocracy'1, but the core point is simpler - 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.
(This is the same mentality that built leetcode interview pipelines BTW, but let's leave that sidebar alone for now)
So the UNIX operator culture tended to operate as a tribal meritocracy (as opposed to the UNIX implementer culture, which fell out of a different set of cultural norms, quite an interesting side bar itself2), a cultural priesthood, somewhat self-regarding, rewarding of cleverness and knowledge hoarding, prone to feats of bravado, full of lore, with a defensive mentality of keeping the flame aloft, keeping the plebs happy and fed, and warding off the barbarians. As we entered the 90s it was already gently in decline, because centralised computing was giving way to the rise of the microcomputer, but the sudden explosive growth of the WWW pulled internet / Unix culture suddenly back into the mainstream with an enormous and public opportunity vacuum. Everyone suddenly has an urgent need to write programs that push text off UNIX file-systems (and databases) and into web pages, and Perl is uniquely positioned to have a strong first-mover advantage in this suddenly vital, novel ecosystem. But it's culture and values are very much pulled across from this previous era.
(Springing out of this, Perl had an, at best grudging, tolerance for 'difficult genius' types, alongside this baseline culture. Unfortunately, this kind of toxic personality tends to thrive in the type of culture I've described, and they do set to help the tone. I'm not here to call out people specifically, because I'm trying to make a point rather than feed a culture war, or dig up gossip, but there were several significant examples, you can probably find lore if you like. I think the kindest way I can describe the compounding effect of this is that there was a strong cultural norm along the lines of "It's OK to be rude, as long as it's for a good cause".)
I remember this tension as always being tangibly there. Perl IRC and mailing lists were quite cliquey and full of venerated experts and in-jokes, rough on naivety, keen on robust, verbose debate, and a little suspicious of newcomers. And very cult-like. The "TIMTOWTDI" rule, although ostensibly liberal, 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. Elevating extreme flexibility like this is paradoxically also an engine of conservatism. If Perl can already do anything, flexibly, in multiple ways, then the language itself doesn't need to change - 'we already have one of those here, we don't need new things'. This attitude determined how Perl intended to handle evolution: the core language would remain stable (a fort inside a fort, only accessible to high level wizards), while innovation was pushed outward to CPAN. You could add features outside of core by writing and consuming third party libraries, you could bend language behaviour with pragmas without modifying Perl itself. The very best CPAN modules could theoretically be promoted into core, allowing the language to evolve conservatively from proven, widely-used features.
On paper, this sounds reasonable. In practice, I think it encoded a fundamental conflict of interest into the community early on, and set the stage for many of the later growth problems. I'm not going to pretend that Perl invented dependency hell, but I think it turned out to be another one of those profound misfeatures that their cultural philosophy lead them to mistake for virtue, and embrace.
An interesting thing I think has been missed discussing the context of the original blog piece, about whether Perl 6 significantly impacted Perl growth, is the fact that Perl 6 itself manifested out of ongoing arguments. Perl 6 is a schism. Here's a oft-cited note from Larry Wall himself about the incident that sparked Perl 6, at YAPC OSCON 2000
We spent the first hour gabbing about all sorts of political and organizational issues of a fairly boring and mundane nature. Partway through, Jon Orwant comes in, and stands there for a few minutes listening, and then he very calmly walks over to the coffee service table in the corner, and there were about 20 of us in the room, and he picks up a coffee mug and throws it against the other wall and he keeps throwing coffee mugs against the other wall, and he says "we are f-ed unless we can come up with something that will excite the community, because everyone's getting bored and going off and doing other things".
(Pause a second and ask yourself about the sort of social culture that both allows this kind of behaviour at public events, and then chooses to embrace it as a key piece of cultural lore)
Perl 6 was really a schism. Perl was already under a great amount of strain trying to accommodate the modernising influx of post dot-com mainstream web application building, alongside the entrenched conservatism of the core maintainers, and the maintenance burden of a few years exponential growth of third-party libraries, starting to build a fractal mess of slightly differentiating, incompatible approaches of those multiple ways to do things that were effectively now table-stakes language features, as the deployment landscape started to tiptoe towards a more modern, ubiquitous WWW3.
So, while I agree that it's wrong to generalise that 'Perl 6 killed Perl', I would say that Perl 6 was a symptom of the irreconcilable internal forces that killed Perl. Although, I also intend to go on to point out that Perl isn't dead, nothing has actually killed Perl. Killed Perl is a very stupid way to frame the discussion, but here we are.
So... Perl 6 is created as a valve to offset that pressure, and it kind of works. Up to a point. Unfortunately I think the side effect really is that the two branches of the culture, in the process of forking, double down on their encoded norms. Perl 5.x beds down as the practical, already solved way to do all the same things, with little need to change. Any requirements for more modern application patterns that are emerging in the broader web development environment, like idk, Unicode, REST clients, strict data structures, asynchronous I/O, whatever? That can either wait for Perl6 or you can pull things together using the CPAN if you want to move right now. Perl 6 leans the other way - they don't need to ship immediately, we have Perl 5 already here for doing things, Perl 6 is going to innovate on everything, and spend it's time getting there, designing up-front.4 They spend at least two years writing high level requirement specs. They even spin out a side-project trying to build a universal virtual machine to run all dynamic programming languages that never delivers5
This is the landscape where Perl's central dominance of 'back end' web programming continues to slip. Unfortunately, alongside the now principled bias toward cultural conservatism, Perl 5 has an explicit excuse for it. The future is over there, and exciting, and meanwhile we're working usefully, and getting paid, and getting stuff done. Kind of OK from inside the fort. Some day we'll move to the newer fort, but right now this is fine. Not very attractive to newcomers though, really. And this is also sort of OK, because Perl doesn't really want those sort of newcomers, does it? The kind that turns up on IRC or forums and asks basic questions about Perl 6 and sadly often gets treated with open contempt.
Ruby has sprouted "Ruby on Rails", and it's taken the dynamic web building world by storm. Rails is a second generation web framework, that's proudly an 'opinionated web framework'. Given that the web application architecture is starting to stabilise into a kind of three-tier system , with a client as a web browser, a middle tier as a monolithic application server, and a persistence layer as a relational database , and a split server architecture serving static and dynamic content from different routes, here is just one way to do that, with hugely developer friendly tooling turning this into a cookie-cutter solution for the 80% core, and a plugin and client-side decoration approach that allows for the necessary per-site customisation.
Ruby is interesting as well. Ruby is kind of a Perl6 really. More accurately it's a parallel universe Perl5 Ruby comes from Japan, and has developed as an attempt to build something similar to Perl, but it's developed much later, by programming language enthusiasts, and for the first ten years or so, it's mostly only used in Japan. To my line of thinking this is probably important. Ruby does not spring from decades of sysadmin or sysop culture. 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 also has adopted 'friendliness' as a core value, and the culture over there adopts a principled approach to aggressively welcoming newcomers, promoting easiness, and programmer happiness and convenience as strong first class principles.
Rails is a huge hit. At this point, which is around about the time I stopped significantly using Perl (2004-2005) (because I quit my job, not out of any core animosity toward it, in fact, in my day, I was really quite a Perl fan), Rails is the most appealing place to start as a new web programmer. Adoption rate is high, community is great, velocity of development is well-paced, and there's a lovely , well-lit, onboarding pipeline for how to start. You don't even really need to know ruby. It has a one-shot install tool, and generates working websites from templates, almost out of the box. It's an obvious starting point.
Perl being Perl, develops several analogue frameworks to Rails, all of them interdependently compatible and incompatible with each other and each other's dependencies, all of them designed to be as customisable and as user configurable as they possibly can be6
There are also the other obvious contenders. PHP has been there all along, and it's almost coming up from entirely the opposite cultural background of Perl. PHP is a users language. It's built to be deployed by copying script files to your home directory, with minimal server side impact or privileges. It's barely designed at all, but it encounters explosive growth all the way through the first (and through into the second) web era, almost entirely because it makes the barrier to onboarding so low as to be non-existent. PHP gets a couple of extra free shots in the arm
There is of course one other big horse in the race in this era, and it's a particularly interesting one in many ways, certainly when contrasted with Perl. This is of course, Python. Python is a close contemporary of Perl's but once again, it's roots are somewhere very different. Python doesn't come from UNIX culture either. Python comes from academia, and programming language culture. It's kind of a forgotten footnote, but Python was originally built for the Amoeba operating system, and it's intention was to be a straightforward programming language for scripting this8. The idea was to build a language that could be the 'second programming language' for programmers. Given that this is the 1980s, early 1990s, the programmers would be expected to be mostly using C / C++ ,perhaps Pascal. Python was intended to allow faster development for lighter weight programs or scripting tasks. I suppose the idea was to take something that you might want to build in a shell script, but provide enough high level structured support that you could cleanly build the kind of things that quickly become a problem in shell scripts. So, it emphasises data structures, and scoped variables, and modules, and prioritises making it possible to extend the language with modules. Typical things that experienced programmers would want to use. The language was also designed to be portable between the different platforms programmers would use, running on the desktops of the day, but also on the server. As a consequence, it had a broad standard library of common portable abstractions around standard system features - file-systems, concurrency, time, FFI. For quite a long time, one of python's standard mottoes was 'batteries included'.
Python never set the world on fire at any particular moment, but it remained committed to a clear evolutionary incremental development, and clean engineering principles. Again, I think the key element here is cultural tone. Python is kind of boring, not trying to be anyone's best language, or even a universal language. Python was always a little fussy, maybe snobby, slightly abstracted away from the real world. It's almost as old as Perl and it just kept incrementally evolving, picking up users, picking up features, slowly broadening the standard library. The first time I saw Python pick up an undeniable mainstream advantage would also have been around the early 2000s, when Google publicly adopted it as one of their house standard languages. Never radical, just calmly evolving in it's environs.
When I sketch out this landscape, I remain firmly convinced that most of Perl's impedance to continued growth were cultural. Perl's huge moment of relevance in the 90s was because it cross-pollinated two diverging user cultures. Traditional UNIX / database / data-centre maintenance and admin users, and enthusiastic early web builders and scalers. It had a cultural shock phase from extremely rapid growth, the centre couldn't hold, and things slowly fell apart.
Circling back though, it's time to address the real elephant in the room. Perl manifestly did not die. It's here right now. It's installed I think by default, on almost every single computer I own and operate, without me doing a single thing to make that happen. It's still used every day by millions of people on millions of systems (even if that isn't deliberate). It's still used by many people entirely deliberately for building software, whether that's because they know it and like it and it works, or because they're interfacing with or working on legacy Perl systems (of which there are still many), or maybe they're using it still in it's original intentional role - A capable POSIX-native scripting language, with much better performance and a broader feature-set than any shell or awk. I still occasionally break it out myself, for small scripts I would like to use more than once, or as parts of CLI pipelines.
What I don't do any more is reach for Perl first to make anything new. In my case, it's just because I typically am spoilt for options that are a better fit for most tasks, depending on whatever it is I'm trying to achieve. By the time I came to Perl, (1998-ish), I was already on my third career phase, I had a strong UNIX background, and had already built real things in lisp, java, pascal, visual basic and C++. My attitude to languages was already informed by picking a tool to fit the task at hand. Boy did I love Perl for a few years. The product/market-fit for those early web days was just beautiful. The culture did have too much of the negative tropes I've been pointing at, but that wasn't really a problem personally for me, I'd grown up amongst the BOFHs inside the data centres already, it wasn't too hard for me to assimilate, nor pick up the core principles. I did occasionally bounce off a couple of abrasive characters in the community, but mostly this just kept me loosely coupled, I enjoyed how the language solved the problems I needed solving quickly, I enjoyed the flexibility, and I also enjoyed the way that it made me feel smart, and en-route to my wizard's robes and hat, when i used it to solve harder problems in creative ways, or designed ways around bugs and gremlins. For a good 3-4 years I would have immediately picked it as my favourite language.
So as I say, I didn't fall out of it with any sense of pique, I just naturally moved to different domains, and picked up tools that best fit. After Amazon, I spent t a lot of time concentrating on OS X and audio programming, and that involved a lot of objective C, C++. The scripting tools in that domain were often in ruby, sometimes python. For personal hacking, I picked up lisp again9 (which I'd always enjoyed in school). I dipped in and out of Perl here and there for occasional contract work, but I tended to gravitate more towards larger database stuff, where I typically found C, java and python. The next time I was building web things, it was all Rails and ruby, and then moving towards the web services / REST / cloud era, the natural fits were go, and of course node and JavaScript or Typescript. I've always been a polyglot, and I've always been pretty comfortable moving between programming languages. The truth of the matter is, that the majority of programming work is broadly similar, and the specific implementation details of the language you use don't matter all that much, if it's a good fit for the circumstances.
I can't imagine Perl disappearing entirely in my lifetime. I can remember entire programming environments and languages that are much, much deader than I can ever see Perl becoming.
Perl also got to be if not first, then certainly early to dominate a new market paradigm. Plenty of things never manage that. It's hard to see Perl as anything other than an enormous success on these terms. Perl innovated and influenced languages that came after in some truly significant ways.
Just these points, and I'm sure there are many others that could be made, are enough of a legacy to be proud of.
Counterfactuals are stupid (but also fun). If I squint, I can imagine that a Perl with a less reactionary culture, and a healthier acceptance of other ideas and environmental change might have been able to evolve alongside the other tools in the web paradigm shift, and still occupy a more central position in today's development landscape. That's not the Perl we have though, and that didn't happen. And I'm very confident that without the Perl we did have, the whole of modern software practice would be differently shaped. I do think Perl now lives in a legacy role, with a declining influence, but that's really nothing to feel shame or regret for. Nobody is going to forcibly take Perl away as long as POSIX exists, and so far as I can see, that means forever. In 2025 too, I can see the invisible hand creeping up on some of these other systems I've mentioned. Rust is slowly absorbing C and C++. Ruby (and of course Rails) is clearly in decline, in a way that probably consigns it to become a similar legacy state. From a certain angle, it looks a lot like Typescript is slowly supplanting Python. I won't be entirely surprised if that happens, although at my age I kind of doubt I'll live to see the day.
1 : Meritocracy is a fun word. It was originally coined as a pejorative term to describe a dystopian mechanism by which modern i.e. Western / British society entrenches and justifies an unfair and unequal distribution of privilege
2 : The UNIX implementer culture, is scientific/academic and fell out of Bell Labs. I guess you could extend this school of thought as a cultural sweep towards building abstracted cloud operations, toward plan 9/ Inferno / go
3 : Web 2.0 was first defined in 1999 by Darcy DiNucci in a print article , the term didn't become mainstream until it was picked up and promoted by Tim O'Reilly (then owner/operator of perl.com, trivia fans), an astute inside observer of the forces driving web development
4: Another unfortunate bit of luck here. Right at the point of time that 'agile' starts getting some traction as a more natural way to embrace software development - i.e. iterating in small increments against a changing environment and requirements, Perl 6 decides to do perhaps the most waterfall open source development process ever attempted. . It is fifteen years before Perl 6 ships something resembling a usable programming language.
5 : The Parrot VM, a lovely quixotic idea, which sadly fizzled out, after even Perl 6 stopped trying to target it. Interestingly enough, both python and ruby both made relatively high profile ports to the JVM that were useful enough to be used for production deploys in certain niches.
6 : A side effect of this degree of abstraction, is that as well as being very hard to get started, it's easy to fall foul of performance overhead.
7 : This ubituitious ecosystem of small footprint wordpress custom installs gives birth to the web agency model of commercial website building / small ecommerce sites, which thrives and is suprisingly healthy today. Recent, and slighly optimistic surveys have pitched WordPress as powering over 40% of all websites today. Now this is certainly inflated, but even if the realistic number is half of that, that's still pretty damn healthy.
8 : It's often repeated that Python was designed as a teaching language, but as far as I know, that's not actually the case. The designer of Python, Guido Van Rossum was previously working on a project that was a intended as training language, called ABC, and many of ABC's syntax and structural features influenced or made their way into Python.
9 : Common lisp is a better answer to an infinitely flexible 'everything' chainsaw language than perl, IMHO
posted by cms on 2025-11-20
tagged as
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.
I'm a white man, and I have never felt "alienated" in so-called progressive spaces.
They have tried and succeeded: https://docs.activestate.com/activepython/2.7/
I still consider the result "broken".
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.
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.
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.
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.
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.
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.
I agree that python versioning and especially library packaging is the worst part of the language, though.
I've met many time some error "haha nope, wrong version, perl 5.31.7 required"
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.
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.
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.
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.
They should've just used Python 2's strings as UTF-8. No need to break every existing program, just deprecate and discourage the old Python Unicode type. The new Unicode type (Python 3's string) is a complicated mess, and anyone who thinks it is simple and clean isn't aware of what's going on under the hood.
Having your strings be a simple array of bytes, which might be UTF-8 or WTF-8, seems to be working out pretty well for Go.
Imagine if the same interpreter supported both Python 3 and Python 2. Python 3 code could import a Python 2 module, or vice versa. Codebases could migrate somewhat more incrementally. Python 2 code's idea of a "string" would be bytes, and python 3's idea of a "string" would be unicode, but both can speak the other's language, they just have different names for things, so you can migrate.
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.
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.
Not without enormous and unnecessary pain.
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.
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'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.