The backwards incompatibility of Perl 6 absolutely killed Perl.
There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use because they still have momentum and lots of legacy things built in them. So being ugly or old isn’t enough of a factor for people to abandon something in droves.
Once you need to rewrite everything, there’s no reason to stay with something you know since you need to fully retool anyway.
As a Perl programmer since v5 was released, the confusion around 6 completely destroyed almost everyone’s enthusiasm, and immediately caused all new projects to avoid Perl. It seemed like 5 had reached the end of the line, and 6 was nowhere to be found. Nobody wants to gamble so many hours of their lives, and the future of their business, on such an uncertain environment.
If Perl 6 had any visible movement within the first few years, it might have survived, but it was a good decade before they even admitted Perl 6 might take longer than expected, and then more time after that before they admitted it should have been a new language. 6 was interesting for language geeks, and they probably did some cool things, but you can’t run a large popular project like it’s a small research project. That completely destroyed all momentum in the community. Perl 5 development only resumed far too late, after the writing was already on the wall.
Both Bill Gates and Linus understand backwards compatibility as a sacrosanct principle. Python only just barely survived the jump from 2 to 3. JavaScript can only survive this because there’s no other option in a browser.
> Python only just barely survived the jump from 2 to 3.
I really don't think this is true at all.
Python 2 to 3 took a really long time, it was a real struggle, lots of people stayed on 2 for a really long time.
But I really don't think Python was close to dying the same way Perl has/is. There was no risk of Python not "surviving" in my opinion.
There was always a clear way forward and people were actually moving. The mass migration of millions or billions of lines of code from 2 to 3 actually happened and has many high profile million+ line migrations, like Yelp or Dropbox.
There was never anything similar for Perl 5 to 6, totally different situation.
1. The data science / AI crowd that was gathering momentum any many only used Python 3.
2. No popular alternative. Perl got python as an alternative.
Python was also a good, simple language and had a good healthy culture. But it's nothing sort of a miracle that it survived that biblical software calamity.
`six` was instrumental in repairing the Python schism by giving people a way to incrementally move their 2.7 code to Python 3, and write code that was compatible in both. The six project didn't exist at first and the path to Python 3 was too painful without it. Six solved all that by smoothing over built-in libraries with different casing between versions, incompatible core libraries, the addition of unicode strings, print changing to a function, etc, etc. Perl 5 to Perl 6 (aka Raku) never got that.
Six was one component but not the only one. Python 2.7 also backported a number of early Python 3 features, Python 2 features were reintroduced in basically every P3 version until at least 3.5 (although after 3.3 they were pretty minor), and a lot of extensive migration guides were written (my main bible was eevee's).
In my experience, six was a relatively minor part, and you could get by with your own little compat file for just the stuff you needed, even on relatively big projects. I even found it beneficial to do so because instead of just slapping six.moves everywhere you'd have to re-evaluate some of the old decisions (e.g. at $dayjob at the time we were using all of urllib, urllib2, and requests for HTTP calls, not using six provided strong motivation to just move everything to requests). This also made for a lot less churn when removing Python 2 compatibility.
> Python 2 features were reintroduced in basically every P3 version until at least 3.5
If they had just done this from the beginning there wouldn't even have been such upgrade drama in the first place... like, as an obvious example, removing u'' syntax for unicode strings immediately at 3.0 was just idiotic: if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all (a la Ruby 2's Unicode reboot, which concerned a lot of people but was a nothing-burger next to the insanity of Python 3).
Sure but importantly they did realise they had erred and course-corrected.
> if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all
Having been there and done that, nah, the text model changes alone required significant work to square up in most packages. And there were plenty of other semantics changes.
But you could have made those changes incrementally in a way that more cleanly worked across both Python 2 (which already had this split: the default type was just wrong; all of my code, for instance, worked great!... it was just super awkward, as it had tons of u's thrown all over the place). Where they ended up with the language (after, like, 3.7) was much more incremental from Python 2 than the early path to how they got there. To be explicit: it isn't about having to put in upgrade effort, it is about upgrade discontinuity.
I’m not talking as a user, I’m talking as a person who ported 350kLOCs of python from 2 to 3.
Django absolutely would have been ported: it was ported without six by Vinay Sajip (building on an earlier work of Martin von Löwis). In fact a limited shim layer was initially committed based on Vinay’s efforts: https://github.com/django/django/commit/5e6ded2e58597fa324c5...
The team ultimately decided to use and re-export six for the convenience of the ecosystem, not out of any sort of necessity.
Python 2.7 was kept very much alive, with a number of small improvements from the 3.x branch backported to it.
Big players, like Django or SQLAlchemy, kept versions both for 2.x and 3.x for quite some time. This allowed for a smooth transition, when all of your dependencies finally had good versions for 3.x.
The difference between Python 2.x and Python 3.x was not dramatic. I would say it was mostly cosmetic up until 3.5 when async landed. Even with these small changes, the splitting of byte strings and character strings alone (an obvious move towards sanity) was plenty annoying for many projects.
Communities and ecosystems are fragile; sharp turns can easily break them.. Even careful maneuvering, like the Python 2 → 3 transition, put very visible strain on the community. A crazy jump that was Perl 6 was not survivable, even though Raku may be a fine language.
> the splitting of byte strings and character strings alone (an obvious move towards sanity) was plenty annoying for many projects.
Python 2 had both, it was a rename, not a split. unicode -> str, and str -> bytes. The "u" string prefix was also removed, which made migration of string-heavy code more of a pain than it needed to be, until it was added back in in 3.3
I was not affected by Py3 at all. First I completely ignored it for five years while it gestated. Then started kicking the tires when 3.4 dropped on a LTS. When 3.6 with better dicts and f-strings landed I moved over with barely a whimper, since I'd had a decade to get things upgraded to 2.7 first.
None of my projects needed to worry much about char encoding, and I'd used logging extensively starting under 2.6 or so.
Porting your own code was relatively easy. The problem was porting all your dependencies, and replacing the ones that were abandoned and didn't support 3.x.
They were ready long before 3.6, sqlalchemy added support for Python 3.1 in 0.6, and Django 1.5 introduced support for Python 3.2 on an experimental basis with 1.6 removing the “experimental” bit.
Long before the AI/data science breakout, we were noticing in our consulting practice (2016-2020) a sharp dropoff in Ruby at startups, and Python as the modal language (by the time I left in 2020, it would have gone Python -> Node -> Ruby).
So no, I don't think AI saved Python; it was fine before then.
2016 already puts one far into the AI explosion. The current hype cycle, with LLMs as a service at the forefront, arguably makes python less relevant than in it was in the mid 2010’s. The current crop of “AI Engineers” can use whatever languages they want for the most part. In 2016 most practitioners were leveraging a lot more of the standard scientific computing frameworks afforded by python.
Python was the lingua franca of data science by 2016, but AI and data science was clearly not the reason startups were building in Django and Flask --- the data science teams were always a morass of Jupyter notebooks and pickle blobs.
I can easily imagine a scenario where Julia could have taken the data science crowd and Node.js could have taken everyone else. People like Python, I guess.
Before JS had promises, JS code was plagued with the callback pyramid of doom. You needed an advanced masters degree in masochism to endure that. I don't think Python devs would have liked that.
I don't know. Isn't Python still viewed as a mess now? I was thinking of taking the time to learn it as the best way to write cross-platform utilities, but encountered a lot of negative sentiment about its ecosystem. And all the environment managers you seem to need for it are a turn-off.
Granted, this is coming from a relative noob who read and followed a couple of "how to set up Python properly" articles and that's about it. But I pretty much decided to spend my time on JavaScript, despite its cumbersomeness for implementing simple utilities.
It's vastly improved now. With uv, many times you can download a new utility off GitHub and run it with `uv run foo.py`, including fetching its dependencies.
Imo the coding part is fine. I have no mayor complains about it. I even like indentation as syntax as long as you use tabs :)
Python is the modern day BASIC. Slow interpreted lingua franca. As long as you are ok with its speed I say go for it. Python is the only scripting language where I maintain constant lingering awareness that every single line of code adds milliseconds to run time. As bad as instantiating new variable costing single digit ms on a GHz CPU. This quickly adds up the more you are trying to achieve.
Example benchmark, Python 3.4:
# Direct Access d['key']: 3.3710 seconds
# Direct Enum Access d[enum.key]: 157.9954 seconds
In latest versions Enums got "fixed" to "only" 3-6x slower than strings! SimpleNamespace to the rescue.
Its got a big standard library so you can do a lot by just installing Python. On a lot of *nix systems it will all be installed already. For simple use cases you do not have to have the environment manager.
I have had few problems with virtualenv in any case.
Where you are most likely to have problems is cross platform deployment. If you are going to package it as an exe for Windows users, and package it for major Linux distros, and whatever you need to do for MacOS etc. its going to be a pain. In that case there are multiple languages that might suit you better than JS.
Python is great for data science. Anything where you need to wrap a C library like BLAS, tensorflow, PyTorch, matplotlib, numpy.
It's hot garbage for writing simple cross-platform utilities because of the need for an elaborate environment setup, painful dependency management, and constant compatibility breaks.
Anecdotally, I stopped using python for several years around the transition period from 2 to 3 because a number of libraries I used at the time were in flux with 3 support (beautiful soup I _think_ was one? I could be misremembering). Ironically, I ended up just using perl for a scraping tool instead, which it's quite good at for quick and dirty scraping scripts (PCRE.) Nowadays I use ruby for that type of stuff...
You're contradicting yourself - if Python had no popular alternative, what would have new people used instead and what would existing code have migrated to?
If Golang was around, it might have killed python then I think. To many, the 2->3 jump made little sense. I honestly wish they just started a new language instead.
I still to this day stumble upon code I have to use 2.7 on, thankfully things like pipx make it easy these days. but still,switching back and forth could be a pain.
But you're right, it wasn't like Perl 6. People moved to python and php mostly from perl. what were going to move to from python 2? Ruby?
Python 2.7 was EOL'd at the start of 2020, and serious effort to move from 2 to 3 didn't start until around 2018, by which time Go was a very major player.
I meant when 3.0 was released. By the time 2.7 was EOL'd 3.0 had gained enough momentum to be a viable alternative. It was easier to just migrate to 3.0.
In 2018, I don't know if Go was a major player, both it and rust were still new-ish languages. There was still a concern of being able to hire devs if you used them, where as not so much in the past 4-5 years.
Major-ish. It was getting experimental module support around 2018; arguably go get was already better than Python's mess, but it wasn't great. It wasn't that widespread in industry yet - we could very rarely hire anyone with a Go background at that point.
Pretty major. I started using Go in like 2009 or 2010 and industry adoption was already pretty wide in the mid 2010s (largely replacing Java moreso than Python, IMO).
Can you imagine if the PSF had been working on Python 4 in parallel, with more backwards compat shifts or even a radically modified syntax?
I think another saving grace was, when considering Python 3, one's choice was between "easy-ish migration to best in class" and "difficult rewrite into second-best". Meanwhile with Perl 5/6 it was "two moderately hard migrations into metastasized shell-script has-been language" and "difficult rewrite into best-in-class with lots of upside".
The delta between python 2 and 3 was much smaller than the delta between perl 5 and 6. Perl 6 might as well be a totally different langue which is probably why they renamed it to Raku, to stop people thinking that it was the same language.
For the crowd I ran in the lack of real branching and the need to use DirState or Queues for selective commits made Mercurial feel too much like p4, where git felt so freeing, especially with spikes etc...which would be forever in the repo with Mercurial etc...
> This ground rule meant that a mass insertion of b'' prefixes everywhere was not desirable, as that would require developers to think about whether a type was a bytes or str, a distinction they didn't have to worry about on Python 2 because we practically never used the Unicode-based string type in Mercurial.
> In addition, there were some other practical issues with doing a bulk b'' prefix insertion. One was that the added b characters would cause a lot of lines to grow beyond our length limits and we'd have to reformat code.
I wonder if their line length was arbitrarily 80chars or some silly serial terminal like limit.
> It is now 2020 and Python 2 support is now officially dead from the perspective of the Python language maintainers. Linux distributions are starting to rip out Python 2. Packages are dropping Python 2 support in new versions. The world is moving to Python 3 only. But Mercurial still officially supports Python 2
To me it doesn't matter what pain points there were between 2/3, or that it was even python.
That is just the classic way any modernization effort fails. IMHO those failures are almost completely tool agnostic and are cultural failures.
Hindsight is 20/20 but that article definitely makes me question the technical leadership of the project. They chose to write a source transformer (which introduced its own set of issues) rather than update string literals to use b'' syntax because they didn't want contributors to have to learn how to use python 3? And because they didn't want lines to be too long? And because it would break change attribution for the lines in question? None of those reasons sound compelling to me at all, but the author presents them as the correct decision.
Python continued growing fast during the 2 to 3 transition, it was nowhere near dying. It was one reason it took so long, people were starting new Python 2 projects 5 years after Python 3 was released. Only around 2017/2018 the default for new projects kind of became Python 3.
Python 2 was used for such a long time because many modules only worked on 2, which was a direct result of the compatibility being broken. There was a catch-22 for a long time that nobody would upgrade to 3 because nobody else would.
You could really make a business case study (well, a project management case study) out of the Python 2 -> 3 transition. It was a very well executed plan. It started with a clear definition of where they were headed (v3) with some good reasons for the technically minded. But the transition itself was really... really... slow.
It was methodical and deliberate, but slow.
But I think it really happened because developers wanted to move to 3. There was enough momentum and upside for moving to 3 that the Python core developers could keep the migration on track without having to drag people along from 2 -> 3 before they were ready. Making sure that the transition was optional for a long time helped tremendously.
I was quite happy working in Python 2 for a long time and only transitioned over to 3 for new projects or code that I thought would have a long lifetime. This was very much a reason why I moved to 3 instead of to another language.
At the same time, I'm not sure what language I would have switched to for the things I was using Python for... Perl was out as it had it's own disastrous migration. Ruby was an option, but never really hit the general-purpose scripting language mark for me.
Uh.. You've started in the middle. Python 3.0, 3.1, and 3.2 were insufficiently compatible to support a migration. If not for the effort to reduce 2 to 3 incompatibility by shipping 2.7 and 3.3, 3 could really have failed. I'd say the initial plan was not so good but then the _replan_ after the first setbacks was good.
I never saw the initial versions as viable versions for production work. IIRC, neither did the authors. Part of what I think was so good about the plan was that it was a parallel track for so long. They didn’t start the process of sunsetting v2 until v3 was ready to take on the migration. The specific steps taken, versions released, that wasn’t what was so good IMO. It was the time scale. This was a good decade long transition. The fact that Python thought it would have that much time to make the transition was audacious, but it was going to take that long. And now we have a better language that has supported many more years of growth.
It took AdaCore so long to port the plugin system of the GNAT Studio (GPS) to Python 3 (which seems to be a fraction of the whole code base), that even conservative Debian had to remove the whole GNAT-GPS package.
> There was always a clear way forward and people were actually moving.
I was always of the impression that people were very reluctant to move even though the benefits were clear and the movement not nearly as difficult as people claimed. But I still hear people complain about, for example, how you can't run CPython 2.x bytecode on a modern CPython runtime even though you can't run CPython 3.13 bytecode on a CPython 3.14 runtime, either and that hasn't slowed anyone down at all.
> the movement not nearly as difficult as people claimed.
Original was really rough because the core team had gone in the wrong direction on migration, and the Python io module was hell as well.
By 3.3-3.4 it was relatively smooth sailing but that took a lot of work from the community and core team both (reminder that Python 2.7 was released after 3.1, backporting a number of features to make compatibility easier, and old features were reintroduced as late as 3.5).
I started on 3.2 and found it reasonably smooth (dealing with encodings in 2.x was also not pleasant IMX if you also cared about universal newline support at the same time), but I will definitely cede that 3.0 and 3.1 were Not Ready.
Not sure why this was downvoted, 3.3 was when they started re-adding things that were removed in 3.0, to make supporting both 2 and 3 reasonable for libraries. I think it kept going in both 3.4 and 3.5 with more features, but the 3.3 restoration of the "u" string prefix is the one that I remember.
Not to dispute the overall premise that Perl 6 did enormous damage to Perl, I want to interrogate this a little bit:
> There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use because they still have momentum and lots of legacy things built in them. So being ugly or old isn’t enough of a factor for people to abandon something in droves.
Nothing forced anyone to abandon Perl 5 code, and I suspect most Perl 5 wasn't abandoned for its own sake; it was a Cambrian explosion of new greenfield projects rising out of the ashes of Web 1.0 that brought Python and Ruby and PHP to the forefront. It's just that a lot of the Perl 5 code out there in the world was quick and dirty CGI scripts that died naturally after the dotcom crash and as the web became more sophisticated.
My take is a lot of that Web 1.0 stuff was total spaghetti code, hardcoded to a table layout, full of injection holes, etc etc. (It was like everyone did my first CGI script x 100.) So in that sense Perl wasn't any different than classic ASP or cold fusion or etc, it became associated with bad legacy code. And because there was no 'Perl 6', people had to choose something else.
(There's stuff about the perl language, but that's probably secondary.)
Yea, Perl thrived while there was no real alternative.
PHP arrived and ate into it's web app use-cases. Modperl wasn't great for hosted environments, to say the least.
Python matured and started eating into it's systems use-cases and eventually the web use-cases as well. And was just so much easier to work with and learn.
Perl was left with no real niche where it really shined, except one-liners and making poetry I guess
>>Nothing forced anyone to abandon Perl 5 code, and I suspect most Perl 5 wasn't abandoned for its own sake;
Perl, Lisp, Haskell, Prolog etc.
I was there when Perl ruled the world, I used it myself to rule the world. The scene was always managers going to the C++/Java teams and asking them an estimate to a get a project done. They would often come back with timeline spanning 1 - 3 years.
Perl teams would get it done in like a week.
Needless to say most non-Perl programmers wanted Perl gone for this one reason alone. Too powerful, people who know how to use it make too much progress compared to everyone else. Smaller teams making larger progress shrinking the head counts, which top bosses didn't like.
Programming world is a sea of mediocrity, good things mostly don't make it here.
I got into Perl in the early 90s in the Perl4 days, watched the very weird but necessary Perl5 come into focus, then I saw Larry and the community in the 2000s get stars in their eyes and just throw it all away for the dream of Perl6.
The real issue is not just that Perl6 wasn’t backwards compatible, it was that Perl6 basically did not exist for real for many, many years. People got tired of waiting, and the lack of backwards compatibility did not help.
Also Perl6 was just more weird on top of weird from a mainstream perspective. Making it even harder to justify.
And killing Perl 5 in the process. If Perl would have kept going in its own pace and Perl 6 would have been named Rapture or Raku from day one, Perl would have been fine.
Nowadays when everyone and their dog (vcpkg) have a package system, it’s easy to overlook how magical CPAN was. A solution to the weirdest problem, just a package away.
It's interesting because you can still find interviews of Larry online how Perl is the first postmodern programming language but for perl6 they came up with a very top-down, modernist project
I had a similar experience. It was so disappointing to watch them bike shed Perl 6 endlessly while Python was gradually taking over.
Even as a die-hard mod_perl fan, I never even tried Perl 6. The language had gone from the most concise and efficient way to process text streams to an incredibly complex OOP language that for some reason had an experimental Haskell implementation, its own custom VM and multiple compilers.
> it was a good decade before they even admitted Perl 6 might take longer than expected
I was there at OSCon when Larry announced Perl6, and that it would be "out by Christmas". And I was there the next year, when he was asked about that, and cheekily replied "well, we never specified _which_ Christmas."
The wider Perl community adopted that, and for years it was a running joke that Perl 6 would be "out by Christmas."
Of course, people outside the Perl community didn't get the joke. They just perceived it as the Perl community making promises about release dates and then missing them. That was some self-inflicted damage.
You can break backwards compatibility, if you are careful.
In fact, Perl even had the tools to break backwards compatibility baked in from the v5 days.
I agree that Perl 6 is why perl died, but I think the thing that really killed it is what you mentioned. It was a completely different language that spend over a decade with a release date of "soon".
Who wants to work on a language that isn't being worked on because the next thing is AND where from what you know of the next thing everything will be a complete rewrite.
A completely different language, a decade of development to Perl 6, and Python eating its lunch in the meantime. Perl is often called a write only language, and there's Python with
for line in file:
If you were new to the field at that time, Python seemed like a no-brainer.
Even as an experienced developer who even owned CPAN modules and was very familiar with the Unix ways, Python was a no-brainer.
I mention this on light of the article's claim that this has to do with "a new generation of programmers brought up on … I don’t know, Microsoft systems, Visual Basic and Java". No. The new languages that appeared were just so much much better.
When you have advantages that often come down to "it works great on a teletype over 150 baud" (read, compressed syntax, regex, etc) you will eventually be beaten by something that is easier to read at a glance.
Non-programmers read python and sometimes even Java and say "huh, this is something that could be figured out" - reading perl was reading line noise.
APL is probably one of the most powerful languages out there, but the characters in the syntax scare most away.
> The backwards incompatibility of Perl 6 absolutely killed Perl.
The insane lead time of Perl 6 to even get to a point of backwards incompatibility was it for me.
I'd started on an early version of perl 4 and went through the 5 transition and was excited about 6. For what seemed like "Duke Nukem Forever" time, and finally my fickleness drew me to other languages and frameworks.
I think more specifically it was the hesitance to move Perl 5 significantly forward in the meantime that caused the damage. That has been decidedly changed the last few years, with great strides being made. That time in between is lost, though.
This is the key - you need to cannibalize from the "new" for the "old" if you're making a grandiose change with no set release date. Perl 5 continuing to get some "back ported" improvements from Perl 6 would have kept it alive for quite a lot longer.
You run the risk of killing the new in the cradle, though, and often that scares people.
Fun fact: The amount of time it took Perl 6 to come out after being announced was actually longer than the amount of time it took Duke Nukem Forever to come out after being announced
There are also a lot of things about Perl that prevented new developers from choosing it when other options were available.
I learned Python from reading a pocket language reference that just described the syntax and standard library, because the language was simple and easy to understand and everything made sense.
Conversely, I was trying to debug a script someone else ran and came across a line that said '$|++'; it was impossible to search for on the web, and when I asked on IRC the only answer I got was 'man perldoc' which also did not answer my question in any reasonable way.
For anyone wondering: `$|` is an alias for `$OUTPUT_AUTOFLUSH`; it defaults to 0 (line-buffered) but any non-zero value means 'flush output immediately'. Thus '$|++' changes 0 to 1 (or 1 to 2, etc), which means that '$|++' means 'turn off output buffering'. No one could be bothered to say that; if you had questions about the language you clearly didn't RTFM well enough so that became the default/only answer I ever saw.
Meanwhile, the PHP community was often welcoming and helpful to newcomers, despite most of them being bad at programming and giving bad advice, and the Python community produced a language that was so often self-explanatory that new user questions were more about how Python did things or asking about how to implement things they didn't realize were in the standard library.
So yeah, lots of things contributed to Perl's decline, but the community being a bunch of elitist toxic dicks sure didn't help matters and it meant that as the set of people looking to learn how to do programming on Linux grew past the neckbeards looking for any metric to show that they were better than other people then Perl's growth potential was finite.
Perl was not and still is not suitable for people who refuse to read the manual or tutorial.
Perl had and still has truly AMAZING documentation (and far better in perl 5 than Perl 6 - where the documentation's search function is regularly broken for example). And out of this world bring-up tutorials. But if the bar is at "I want to be up to speed after reading a short booklet" - well, that's not gonna work. For me I have programmed in perl for decades and I still get the occasional deep plunge in a feature area that I never used before... And the various docs and books still come through.
On top of that, Perl 5 had an amazing community ready to help - but understandably annoyed with constantly re-quoting the AMAZING documentation. It could have gone either way, it just went the way it did: experts present and ready to answer. But there too - if you expect the community to constantly answer the most basic questions, well, Perl was not for you.
As a tradeoff perhaps, that expert community also spent a lot of effort on the AMAZING module library.
Perl 5's thorough documentation, plus splendid course book, plus all the books, plus CPAN, PLUS the expert help producing fantastic rabbit holes to learn more about your PROFESSIONAL MEDIUM. THAT was the reason for choosing perl.
If anything, newcomers don't go to the documentation because they are not aware that documentation can be THAT good. That was, still is, a marketing error.
That's an interesting observation - and my recollection is that the perl heyday was just about before the Googlefication of the world; certainly before stacked overflowing.
Grab a snippet of Java or Python and you can google it pretty easily, grab some line noise from perl and you would first need something to translate it into idiomatic text - search engines would search for "OUTPUT_AUTOFLUSH" but would often discard things like "$|++"
I remember learning my use of perl from a red book - probably "Perl 5 by Example" - everything was in books back then, and you read them. Now you learn programming via searches and LLMs, so the languages that win going forward are going to be the ones optimized for that.
> search engines would search for "OUTPUT_AUTOFLUSH" but would often discard things like "$|++"
Out of curiosity, I tried
perl "$|"
in DDG and Google. DDG returned nothing, but Google led with "perl $|=1; What is this?", and "Perl, what does $|++ do?", both from Stack Overflow. Search like it's 2014, eh? I don't have a time machine, but I'm pretty sure that quoting would've worked ten years ago, too.
When I asked a question on the PERL Usenet group in the 90s, I used the word "newbie" to describe my skill level. I got an automated email explaining why I shouldn't use that word.
> when I asked on IRC the only answer I got was 'man perldoc'
Your overall point notwithstanding, this was just bad advice. What you want is `man perlvar` (or equivalently `perldoc perlvar`) which documents this and other predefined variables:
HANDLE->autoflush( EXPR )
$OUTPUT_AUTOFLUSH
$| If set to nonzero, forces a flush right away and after every
write or print on the currently selected output channel.
Default is 0 (regardless of whether the channel is really
buffered by the system or not; $| tells you only whether you've
asked Perl explicitly to flush after each write). STDOUT will
typically be line buffered if output is to the terminal and
block buffered otherwise. Setting this variable is useful
primarily when you are outputting to a pipe or socket, such as
when you are running a Perl program under rsh and want to see
the output as it's happening. This has no effect on input
buffering. See "getc" in perlfunc for that. See "select" in
perlfunc on how to select the output channel. See also
IO::Handle.
Mnemonic: when you want your pipes to be piping hot
Also, `man perl` gives a great overview of the extensive number of Perl-related manpages. I think any person that starts from `man perl` will be able to answer a lot of their questions, but part of the problem was that around the millennium, people stopped reading man-pages, and started looking for information on the web. perl was one of those old-school tools that were documented extensively in man-pages, but past 1995 ~nobody bothered to read man-pages anymore.
Fair enough, but I think the first part of the advice would be a lot more helpful if it included the second part too. It's the intermediate step that turns people off: why do I need to learn about `perldoc` when I asked about `$|`? (And that's assuming the question asker is familiar with man-pages to begin with, otherwise, you need to read `man man` first!) It feels like you're sending them off on a wild goose chase, even if that's not your intent.
In the millennial web forum world, a n00b would ask "what does $| do?" and the answer would be "it disables output buffering", which is what the n00b wanted to know in the first place. It's the Stack Overflow model of giving men fish, instead of teaching them how to fish.
And in today's LLM-powered world that's only more true. If you ask ChatGPT "In a Perl script, what does $|++ do?" it will immediately give you a correct and concise answer, not make you read `man perldoc` first.
Yes, it would look and work better if presented with an explanation like "you can find any var description by using...". But as I commented already in another thread there was a widespread belief in 90s-00s that users who ask about already documented pieces are being uncivil, not vice versa. So it's not about Perl community per se. The same was norm in many Linux fora, for example.
I remember being very enthusiastic about helping people on, say, Stack Overflow. It didn’t take much extra effort to be nice and made me happy.
But I also burned out relatively quickly. I’d happily answer new questions nicely, but the third or fourth time I saw the same question I spent much less effort to give a welcoming answer than I had the first time I saw it.
Of course, getting the same question repeatedly may suggest something should be redesigned.
I don’t know any good way to keep helpful volunteers helpful for a long time. The best idea I have is constantly recruiting new experts to continually replace the ones that burn out and chase off newbies.
> getting the same question repeatedly may suggest something should be redesigned
Yes! There was a lesson in that and we all missed it. That was probably one of the failings of perl. It ran into a generation of people who never knew about "man pages", or couldn't read (jk - but only somewhat: for some people reading is very hard because various flavors of ADHD, dyslexia, executive disfunction, whatever) and the man page is then useless, or they go to google first and '$|++' failed (because google was raised on python).
Better marketing of the documentation would have helped.
I would say "we'll do better next time" but then perl 6... I'm not happy with perl 6 documentation. There is a lot of it - no problem there. But it insists on living online which necessitates a hosted search function. Which is always broken. And there is still no "local doc" solution.
man I hate that always online stuff. why isn't there the comprehensive man pages thing for perl 6? rhetorical question tho, I don't have much interest in perl 6.
If they specified ‘perldoc -v $|’ instead of just ‘man perldoc’ I’d have been thankful for that as the entire response. It’s literally a pointer to where the answer is and to how to use the canonical tool to find it.
I agree in general (and already commented on this). But some people believe it's like giving fish instead of fishing rod. And I think it was prevalent idea in tech circles during 90s-00s that people who don't read that fm waste other participants time, and needlessly multiply forum topics or extend conversation history. Which was seen as uncivil behavior in those times.
Yep, especially when so many instances of TFM were awful. Perl's docs were fantastic, or so at least I thought at the time, but they were the first large open source project docs I devoured. I can imagine someone coming from another language not even considering just looking at the man page because they were used to awful documentation.
You are right, Perl's docs are so unusually good that newcomers can't believe they don't need the internet to find clear answers, and go searching/asking anyway, sometimes in wrong places.
FreeBSD has the same problem: plenty of its new exploring users dismiss the most well-intentioned advice to read its excellent Handbook as a sort of joke.
I’ve seen that one firsthand! “I want to do a thing.” “That’s in chapter 5 of the handbook.” “Oh cool. Is there a substack or something that explains it?”
There's no space for doubts at all. If it starts with $ then it's a scalar variable name. It's a very basic rule in Perl. Like any Perl tutorial would mention it within a few paragraphs from the start.
Smokey, this is not 'Nam! This is <Perl>, there are rules!
'$' guarantees a scalar. Then it either alphanumeric id, or a single non-alphanumeric symbol. And the latter means you deal with a 'special' var which with 100% certainty has a documentation entry.
That variable in particular gets covered in the Llama book as well. Anyone serious about learning perl in the 90's had at least one of the Camel or Llama books.
A professional medium might have been gate-kept being paying coursework. Perl was not: the super-complete documentation was right there, in the distribution; the remarkably intelligently written course book was right there on everyone's shelves and in your local public library; the in-depth books same thing; And quickly enough even free on the net; the expert-built module library was all there to use and study; the experts were giving their time freely, writing deep dive articles at the simple prompt of worthy questions in addition to columns on topics which I guess were not getting enough questions.
For a professional medium, the only lack that I can tell is from a marketing point of view: installing the distribution for example, probably did not highlight enough how extensive the documentation was.
Sorry for being salty earlier, but learning a language still takes at least a day or two of solid reading of the official manuals. https://perldoc.perl.org if you want a web version.
There was a fifteen year period where the best way of finding out what something meant in a programming language was to Google it. Pre-AI, post the predominance of newsgroups and offline documentation.
Try googling "$|++". It just doesn't work. Never has.
Now Google "file.flush". First hit is the answer you need on SO.
You did not need to google anything. The complete documentation was right there, next to the interpreter, on your machine. Ready for scanning and reading from top to bottom; and broken in sections that were actually relevant; and ready to search in bulk if you prefered with whichever local search tool you cared for.
No need for google. (And google was run by python fans; probably saw no need to support searching for '$|++'.)
And I notice "post the predominance of offline doc". Well that's one problem right there: As of 2025, there is still nothing that beats perl 5 docs as ~260 man pages. Probably LLM-based AI is getting there, at least for people who have difficulty with text. But for the rest of us, it's VERY useful to know that there is solid (offline) doc.
Also to be fair, a modern Perl app doesn't even need to use `$|++` since the framework, even if it's raw Plack, will manage output flushing for you since you're no longer banging on raw stdout. I'd say Perl suffers from an even worse problem of legacy tutorials than PHP, but the size of PHP's userbase and thus sheer number of bad tutorials makes it worse there.
is too curt, and therefore may feel hostile especially for native English-speakers who are used for polite communication to be more wordy. But cultural things aside it's actually a good working solution.
I disagree, at least when it comes to the web (of those days). What's the point of rewriting what's already well- and accurately-written in the docs? What better job are the people on that message board going to do with regards to such a small, specific syntax feature? The point of those "communities" wasn't to answer questions like "what is this variable?" but rather to have actual discussions on the language, such as how to structure applications, design patterns, projects, etc. Imagine trying to build an online community for this purpose, only to spend your days answering the most basic questions possible that were already explained many times before.
Eventually, a website more tailored to such questions was created - Stack Overflow - and there things were very different than in subject-specific communities: there was no "community", there were no discussions, just a big mess of questions. It had a purpose and it served it well. Now it's dying too because of LLMs, but I digress.
Now, in a different scenario, say a colleague asking you that question at work, a direct answer is warranted, but without letting the colleague know that this information and a lot more is a just a few keypresses away would be a wasted opportunity, and not particularly a good way to help that colleague progress.
You can only spoon feed people so much. At a certain point relying on other people to just give you the answer every time you don't know something is lazy. It's like you have no respect for their time.
Golly. There are still some who think it is ok to be rude to newbies.
$|++ is arcane to anyone not steeped in Perl
The newbies could be warmly welcomed and shown respect.
But no, RTFM.
That is rude to somebody drowning in newness. If you do not want to answer their question, then don't. But some people seem to get a kick out of being rude to weaker people
All the times it happened to me, back in the '90s this made life really much harder than it needed to be.
>Golly. There are still some who think it is ok to be rude to newbies.
the entire tech industry is driven by humans and we're really bad at everything. once the AIs take over things should be much better, except for the occasional hallucination.
> made life really much harder than it needed to be
If only you had read the manual...
Seriously though, of course I wasn't advocating for rudeness, and trust me, I remember how rude some people were back then in tech-related boards, this was not a unique Perl thing. I'm advocating for pointing people to the sources of information they're looking for.
> You've made my shitlist
Well then I hope it's posted somewhere I can refer to at will so that I don't have to ask you on a message board like a noob.
The problem is with man pages themselves. You shouldn't have to read 100% of something to find 0.1% of something. In fact, this concept is covered extensively in CS theory about sorting. Reading a manpage is less efficient than asking someone who already knows.
Only locally, only for you, and only short term. You are wasting the time of the person you are asking, and you are learning absolutely nothing about the context of the answer. When the next question arises, you won't even know where to look, you will only continue wasting other peoples' time.
That's a false assumption that the man page even has the info you need. There are channels to write bugs against code, but almost nothing to file bugs against man pages. That's not even a concept to most people, that it's a bug when you apply a use case (say, to apply eui-64 to SLAAC in IPv6 in order to generate a consistent address) and cannot find the information using the man page. If you filed a bug that the man pages failed you nobody would fix it because it's not sexy, glamorous work. Its easier to tell someone to RTFM.
In this case, you would have to already know about the existence of eui-64 to know that is what you want. I've seen this many times, you have to know what the thing is already, or know what the answer is to your problem, in order to find it in the man page.
Total waste of my time. I don't care if it's free or was created by volunteers, that isn't absolution of criticism when it represents something and fails to deliver it.
Nonetheless, you are expecting other people to know the manpage and read it for you. That is a game you may be able to play with paid support, but usually not even there: They will be more wordy and polite, but in essence tell you to RTFM as well.
Bugs in Perl modules that are documentation related are normal bugreports and patches in the normal patch flow because documentation is embedded as POD within the source code.
Your example is very specific and weird (and maybe not even Perl-related). From which you deduce that it is OK to waste the time of volunteers because once one manpage failed you and you decided to never read any manpages again. You only seem to care about your own time, not anyone else's. That is not how anything works on this planet, either you deal with volunteers, where you have to make them care about your query by being considerate, friendly and respect their time as well as you would like yours respected. Or you are dealing with paid support, in which case you have to make them care by paying them for their time by the hour.
There are some manpages which are too long, and cumbersome but it's not a widespread problem I believe. In particular man perldoc is laconic and on point.
I don't think that RTFM is the best form to answer, but those who auto-reject "man" as an answer are definitely missing something important
The trick is to already know how to use regexes to make searching the manpages easier! But you really have to nail down the rules for escaping when you want to search for perl's gnarliest sigil magic.
The man pages were broken into competent sections over multiple man pages. About 260 of them on this machine (not really: there is a change-tracking man page per release recently.) The 1st man page is a very compact index to them.
After that, each section is long but very searchable.
But I can see how many people never even noticed."Man page? what's that? what for?"
But if every user is expected to read the entire manual cover-to-over before asking a question about a four-character operator, what's the point of dividing it into sections?
I know you are not serious but let's go with it anyway. Since we have to be welcoming to newbies :-) Not expected to read cover to cover. Cover to cover would be the tutorial / course work. And even then in a layered language like perl 5, the later chapters only when needed. Layered: the language and coursework is written to add one layer of the language after the previous ones. So you can start writing things that do function after just the first layer.
Expected to know it's there, navigate through it to find the operators or system variables and that you can search through the thing. There are ~260 perl man pages on this computer - not expected to read them. For damn sure expected to use them.
Do read one more section from top to bottom now and then - if the thing is the one fundamental tool in your job!
But that's what the ancestor was trying to do. Then he ran into a symbol he hadn't gotten to yet, asked about it, and got flamed for not reading the full manual!
It was not for not reading the full manual. It was for not using the manual. Somewhere between "not at all", "not competently", "not persistently". And he was pointed to a perl-specific tool which is made for searching the doc. Not the same thing?
And he/they had missed an entire category of symbols. That none of the responses pointed at - their bad on that. That is, all these symbols are described in the same manual section. And used in illustrative examples all over the place. They are not exactly a deep hidden thing.
Also, regarding "flamed". No. Not really. They were handed the same response that countless other questions were getting. Anyone frequenting these forums saw them countless times. It is quite possible that it was their first time on that forum / chat and then that the answer was shocking and traumatic. Yes to that. So that in hindsight, the standard response should have included a pointer to a "how to use the doc" doc. That would have helped. Since it was a generation was seemed unaware of the man pages.
The problem is the implicit assumption that you can throw an entire book at someone and expect them to be able to figure out where to look for each piece of information in it without them knowing beforehand what things even are. If someone hasn't ever seen a variable like `$|` before, it's not necessarily going to be obvious to them what it is, and without knowing how to classify it, they aren't going to know how to tell what chapter it's described in. You're defining the bar for someone to be able to ask a question as high enough that they spent enough time reading through everything to be able to identify it. That's going to be fine for some people, but not everyone learns the same way, and when some people learn better a different way than you, it's not because they're stupid or lazy, but because there's just a lot of variety in what works well or doesn't for people.
Of course, you aren't under any obligation to spend time helping people who you don't want to, but if a community as a whole reacts this way when someone asks a question, they're making the bet that the there are enough people who are similar enough to them to sustain things in the future. Given that this both happened years ago to the parent commenter and now again when they tell the story again, it's not really that hard to believe that this might have been common enough that a lot of people experienced it. The entire point of this thread is discussing why Perl has faltered, and your explanation in the last paragraph comes across as basically saying "kids these days..." in slightly different words. I'd argue that even if the kids loved man pages, having a condescending attitude towards them would probably still come through in other ways, and that would have had pretty much the same effect.
I am agreeing with you that there was a mismatch between the expectations on using the elaborate documentation in its various forms and the tutorials and the stellar course - and a large set of potential users. Nobody expected "the entire book" but perl 5's rise came at the time when many stopped reading man pages, and many projects stopped providing them.
I agree with you that this probably was a contributor in some people giving up perl quickly. For python or php.
Like I mentioned elsewhere, for people for whom using a book would be a barrier - perl would have been a poor choice anyway. You can't program in perl without using the man pages and books. It's a large language, with lots of features purposely made less visible to the newcomer.
In addition, many people were exposed to perl from web scripts. And it was sooo tempting to just paste in a perl script, and then want to modify it, without spending any time on learning the language. Perl makes that frustrating (and compensates with a stellar course book). I still defend perl by arguing that (in perl) there is no point in discussing what $| might mean even before having covered the basics, for example sigils. The course book is layered, and for good reason: to let you write a program in useful order, fundamentals first. The special variables come up fairly early but then again the course book had an extensive index which includes these special variables first in a symbol section, and then again in the alphabetical order for their wordy version $| or $OUTPUT_AUTOFLUSH. I'm not trying to beat you over the head with the manual. Just pointing out that the course book was throrough and intelligently written.
I'll point out that throwing a question at a forum without poking around it a little to figure out the local mores - well, still now, that will get you barked at. Lesson: Forums would do well to provide a more useful paste-in than "RTFM" - ready to go for their users. Instead of "RTFM". At least if they want to foster adoption. Does any forum do that particiularly well, that you have noticed? Most discords for example, do NOT do that well: it's possible to create stickies and they are really not visible. So people create onboarding documents which then get too long and get skipped. A problem not solved there.
Sorry for the bad experience you had, I believe it's always better to be kind to strangers on those global nets. But TBH perldoc would really work very well for you.
> Both Bill Gates and Linus understand backwards compatibility as a sacrosanct principle.
I will always bang the drum for Java for doing this well. Making changes to a heavily used language is _hard_. Sure, the speed of progress can be slow, but Java has managed to introduce major improvements (and deprecations) without causing a schism. That deserves respect.
I feel like time and again language designers don't properly uphold backwards compatibility as a high enough priority, to their and their users detriment.
My team has recently ported 14 Ruby services along with over 50 separate Gem libraries from ruby2 to ruby3 where THEY CHANGED HOW FUNCTIONS INTERPRET ARGUMENTS! Older code run on newer runtimes _change behavior_ for the same code by treating splatted arguments differently, which was _very_ annoying to figure out and reason over for codebases that _heavily_ used '*' splatted arguments.
I feel like folks need to take page from Java's book and maintain backwards compatibility as a core tenet of their language. I've done perl4 -> perl5 -> raku, python2 -> python3, ruby2 -> ruby3, and rewriten a handful of c++, rust and node applications because everything in those landscapes seems to be in constant flux...
I just want to write software that will continue to work after it's been written, without having to use an older CVE-ridden language runtime every time. From personal experience, only java seems to 'get it.' (I'm sure there are others that do get it, but sadly I've had little opportunity to use them.)
Nope, the closest thing to a a breaking javalang change is adding new keywords like var. Outside of the language itself, java's standard libraries have undergone some depreciations and packaging moves (moving javafx, etc.), but absolutely nothing like breaking core language constructs, syntax or behaviors across revisions. I would expect standard libraries to have some deprecations across a 20+ year span.
However, I'm of the opinion that "standard libraries" should be much more minimalist and than javas: move as much as you can into a "core" library that isn't necessarily part of the language, just an optional runtime component following semver so you can be sure pinning a major version will work for essentially forever. Java isn't perfect in this regard, but it sure as hell better than what perl, ruby and python have done in significantly less time than javas...
> Python only just barely survived the jump from 2 to 3.
In the timeframe we're talking here (late 1990s), that transition was Python1 to Python2! A couple Linux distributions were on Python 1.5.2 for a very, very long time. All y'all forget that what Guido, et al. did for the Python 2 to Python 3 transition was informed by the grief they hit in the Python 1 to Python 2 transition!
I would argue that really "What killed Perl" was that people started writing bigger scripts than one-liners. Perl has a well-deserved reputation for being a "Write Only(tm)" language. Python (and really just about every scripting language of the time) was simply better for containing complexity and easier for a newbie to understand.
I remember taking printouts of Perl and Python scripts for the same task to job interviews. The Perl one always had some surprise for the interviewer no matter how hard I tried to remove them. The Python one ... was simply straightforward.
> There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use
What's an example of a language that's as bad as Perl, that's used as widely as Perl was, that's still in use today?
Perl died because everyone who mattered knew it was a bad language, knew it had to undergo drastic changes, but that essentially meant implementing a new language.
Perl 6 was the symptom, not the cause.
---
Note: by "bad language", I mean bad for anything much beyond the kind of thing you might use awk for. It was bad not because of subjective aesthetic issues, but because it was difficult to maintain non-trivial code bases. Its "write only" reputation was well-deserved - the original author of a non-trivial Perl program might be able to maintain it, but once a team is involved, forget it.
You say it was a "bad language" for projects of any real size. But I've worked on large systems written in perl maintained by multiple teams. Perl wasn't the source of our difficulties.
The real issue was ugly code that was in the product when it was acquired--you can write 2000 line methods in any language if you are cursed enough. Believe me, if you do this, you will be cursed.
We dealt with the flexibility of the language by defining clear guidelines on what approaches were recommended and what misfeatures were banned.
I'd go so far as to argue that the expressiveness and flexibility of the language was an asset that helped us in our refactoring. For example, we built instrumentation that took advantage of Perl's unusual semantics for dynamic "local" variables to create flexible instrumentation that could have log levels enabled based on the call stack--if you turned on aggressive logging in function A, it would propagate to A's calls into functions B and C, while other calls to B and C would be logged at normal levels.
Yes, it's possible to do this sort of thing in other languages using a singleton that tracks logging context, but the dynamic scoping gave us the tools we needed to build something powerful with only a small amount of clear, commented code.
Interesting to hear that perspective. But you touched on where I'm coming from:
> The real issue was ugly code that was in the product when it was acquired
IME, this was the norm for Perl projects, not the exception. And you explain the reason for that:
> We dealt with the flexibility of the language by defining clear guidelines on what approaches were recommended and what misfeatures were banned.
Yes, it's true that a disciplined, mature, skilled team can write good code in any mainstream language. But in practice, there are far more teams that lack enough of those qualities, that using what I'm calling a bad language will contribute to them producing hard to maintain, buggy code.
If you're defining a subset of a language as being good, you're proving the point about the overall language not being good. This is why Perl failed - because its real-world use more often than not produced poor outcomes.
> Yes, it's possible to do this sort of thing in other languages using a singleton that tracks logging context
That doesn't sound like the right approach - it sounds like you really want the opposite of a singleton. In most languages, you'd just pass a different logger instance, either as an argument or in an object field.
> What's an example of a language that's as bad as Perl, that's used as widely as Perl was, that's still in use today?
PHP? I don't know how widely it's still used, but I'd guess it's more widely used than Perl. Also, PHP is not "as bad" as Perl. It's much, much, much worse. It's Perl without the charm.
I think it really comes down to, do new young users want to use your language? I don't think perl5 vs perl6 scared off those users. I think the language design is outdated for what people want from computers today.
Indeed. Coming from UNIX tools (sed/awk/sh/grep/tr etc), perl had a lot of appeal and almost intuitive syntax - alternatives in the '80s being C, awk, or if you were unlucky, FORTRAN IV without string type :-). The benefit of having a single language with all of the functionality of these tools was amazing at the time and ability to use familiar syntax was a benefit. However expectations for programming languages grew somewhat since...
> The backwards incompatibility of Perl 6 absolutely killed Perl.
I think the backwards incompatibility was a minor issue compared to how long it took for Perl 6 to be released. It was eighteen years from the announcement to the first (just barely) usable release. And for a lot of that time, I was hearing tech leads say things like "we don't want to start this project in Perl 5 if Perl 6 is just around the corner."
At some point, they changed the narrative from "Perl 6 is the next version of Perl" to "Perl 6 is a sister language to Perl" - but they should have renamed it at that point instead of waiting another 5 years.
It's worth remembering that the Perl 6 project was started because Perl usage was stagnating. But the project was so badly managed that it killed off both Perl 5 and Perl 6 (now renamed Raku).
I don't think it was just the backwards incompatibility on its own. I think perl would have had a much better chance if perl 6 had been ready sooner. The long period of time between perl 5 development stopping and perl 6/Raku being ready for production made the transition much, much rougher than if perl 6 was ready from the beginning, or if perl 5 development had continued, and moved closer to what perl 6 would be while perl 6 was still in the works.
Well, what Perl code is not real-world? And by ugly you mean what - not verbose or what? Something is ugly for ones, but nice to others. I doubt that really is a factor driving a demise of language, otherwise features like regexes would be non-existent today.
It's just a completely different model. Scalar context vs list context. @x returning length vs $x[0] accessing the list. It has a logic but it's its own logic.
Not unlike Rust's borrow checker but at least with Rust you know what you're being promised.
Which is covered in the very first section of the course book? Yes it has its own logic. So do lots of programming languages.
How far do we need to take "not reading the doc"? That the very first chapter is too far? People who gave up on perl because of that... really would not have survived the rest of the course anyway?
You can learn Python, PHP and (a bit less) Ruby without ever touching a book, and definitely you can skip over the first chapter if you're an experienced programmer.
There must be a reason why they made sigils more "traditional" in Perl 6, for example.
> People who gave up on perl because of that... really would not have survived the rest of the course anyway?
I didn't give up on it, I just didn't feel the need to stick with it. I switched to something else that required less of a context switch when going back, awk or jq or Python.
Now, jq is something that throws me off every time I use it. But it's a completely different processing model, whereas lists and hashes are not specific to Perl.
So, to touch on that, no contest that for a while now, you can have a well paying job only writing python. (And perhaps even never going through a formal course on it.) That has worked for many people.
> There must be a reason why they made sigils more "traditional" in Perl 6, for example.
Eh. Sigils are even more present / visible in perl 6. And other compact notation devices. All the way to making up your own unicode-based line noise when it serves. Which it does.
Yes, I didn't say that sigils went away. But for example in Perl 6 lists are @ whether you declare or access them, instead of the sigil changing depending on what you want to get out of the expressions. It says it in one of the first apocalypses even that people "found it a bit weird": https://metacpan.org/release/AUTRIJUS/Perl6-Bible-0.30/view/...
And at least with Rust, even if you don't love it, you can appreciate that there's a compelling reason for it to be that way. I wrote a lot of Perl, but never reached the aha moment where I understand why its sigils were so deliberately odd.
> It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
> Now, however it was initially intended, I think BASIC turned out to be one of the first major scripting languages, especially the extended version that DEC put onto its minicomputers called BASIC/PLUS, which happily included recursive functions with arguments. I started out as a BASIC programmer. Some people would say that I’m permanently damaged. Some people are undoubtedly right.
... but it wasn't without previous examples that Perl went the way that it did with sigils.
I'm familiar with those sigils from various places. Me on my childhood C64: "What does 'B dollar sign' mean?". It just boggles my mind that someone writing a brand new programming language would use them when there were English-like alternatives (like `my foo = keys barHash`). It was sometimes hard to remember what [sigil][name] was going to if you didn't already remember what [name]'s, erm, inherent type?, was. Like is $foo going to give me the string that was already in $foo, or perhaps the number of (occupied buckets)/(total buckets) if $foo is really a hash?
I was able to reason my way through these things and had luck writing reasonably large Perl programs. It did absolutely zero to help make devs' lives easier, though.
In 1987, when your audience of bash and awk and sed users was looking for a language to bring those together and were familiar with them... why wouldn't you use them?
I would also contend that given the tools at the time (vt100 terminals without syntax highlighting being prevalent systems) sigils made it easier to write more on a line, provided easier visual recognition (for those familiar with the language) about the syntax, and provided for a more easily written lexer.
As a very long-time Perl developer and FOSS contributor, I think this blog post is incorrect about whether Perl 6/Raku was a factor in Perl's decline. I think Perl 6/Raku did a few things that hurt Perl 5:
1. It pulled away folks who would otherwise have spent time improving Perl 5 (either the core or via modules).
2. It discouraged significant changes to the Perl 5 language, since many people figured that it wasn't worth it with Perl 6 just around the corner.
3. It confused CTO/VP Eng types, some of whom thought that they shouldn't invest in Perl 5, since Perl 6 was coming soon. I've heard multiple people in the Perl community discuss hearing this directly from execs.
Of course, hindsight is 20/20 and all that.
Also, even if Perl 6 had never happened the way it did and instead we'd just had smaller evolutions of the language in major versions, I think usage would still have shrunk over time.
A lot of people just dislike Perl's weird syntax and behavior. Many of those people were in a position to teach undergrads, and they chose to use Python and Java.
And other languages have improved a lot or been created in the past 20+ years. Java has gotten way better, as has Python. JavaScript went from "terribly browser-only language" to "much less terrible run anywhere language" with a huge ecosystem. And Go came along and provided an aggressively mediocre but very usable strongly typed language with super-fast builds and easy deploys.
Edit: Also PHP was a huge factor in displacing Perl for the quick and dirty web app on hosted services. It was super easy to deploy and ran way faster than Perl without mod_perl. Using mod_perl generally wasn't possible on shared hosting, which was very common back in the days before everyone got their own VM.
All of those things would still have eaten some of Perl's lunch.
I think this is mostly the correct take. Perl's strength is that it was really good and quick and dirty one-offs, especially with text manipulation. This made it particularly popular with UNIX sysadmins and sometimes network admins. This was helped by the fact that CPAN made it easy to share a lot of these, which added to its popularity (it can't be overstated how revolutionary CPAN was).
The 1980s/1990s was full of many different data formats in a time before XML/JSON, often by long dead companies. Many a tech person was in a situation where "Oh fuck, how do I get this data out of some obscure database from some dead company from Boston that only ran on SCO UNIX into SAP/Oracle/etc" only to see somebody else already done it and made a CPAN module.
But stories like that became less common as DBs converged into a few players.
Yeah i'll say, even to this day, when I need a quick script and bash just isn't doing it for me I'll just write it in the same perl I used regularly as far back as 1998... but it never goes further than that. If I have to take that script and build it into anything that will ever leave my laptop it's going to get rewritten in something else (probably golang since it is universal on my team).
I would also say -- in the late 90s, Perl's claim to fame was that it had CPAN. At the time, CPAN was revolutionary: a big, centralized repo of open-source libraries, which you could install with a single command.
Now, of course, that's a common and maybe even expected thing for a library to have: Python has Pypi, Javascript has NPM, etc.
And the whole culture around CPAN, too, with the likes of Module::Build and Test::Harness and the strong expectations around POD documents. Nothing like that existed for the other scripting languages of the time.
There was a well-trodden path from writing a hacky one-off script to deal with a specific task, to realising "hey! this might be useful for others too!" and trying to make it a bit more generic, to checking in with your local Perl Mongers for advice, to turning it into a well-tested, well-documented CPAN module.
That was the route I followed as an early-career sysadmin in the dying days of the dotcom boom - it helped me take on much more of an "engineering" mindset, and was an important foundation for my later career.
I can't have written more than a few dozen lines of Perl in the last 15 years, but do I owe that community and culture a lot.
I love tcl. My absolute favorite thing about it is that `man tcl` [1] gives a dozen paragraphs that completely describe the language itself. Its simplicity always astounded me since it seems really simplistic but at some level it’s just as malleable as lisp. I wish it had caught on more (outside the hardware community which seems to have fully embraced it).
I was a Perl programmer from the early 1990s until into the 2000s and I mostly agree with you. It was a variety of factors.
The point where I disagree is I think Perl 6/Raku played a significant role in Perl's decline. It really gave me the perception that they were rudderless and that Perl probably had no future.
Other than that, I absolutely loved Perl. I love the language. It's super expressive. I never took a liking to CPAN. And I wonder if it could make a comeback given better dependency management.
I think Perl with tooling similar to uv would cause me to switch back today.
> The point where I disagree is I think Perl 6/Raku played a significant role in Perl's decline. It really gave me the perception that they were rudderless and that Perl probably had no future.
I assume you disagree with the blog post, not with my comment, since this is exactly what my comment says too!
Between perlbrew and cpanm it's pretty easy to have multiple perl installs with different versions and quite simple to manage your dependencies.
Carton (manage and bundle your perl modules based on lock files) and Pinto (easily run your own private CPAN) provided the icing on the cake that made things really powerful.
I miss working in Perl, but the job market has pulled me in other directions.
This combined with a cpanfile is how I rescued someone else's workshop from being an "Install these missing dependencies" session to being back on track in 3 minutes with "Here's this file, run 'cpanm --installdeps --notest .'"
You mention it last, but I think PHP was most of it. PHP was the first and best-integrated technology for this world, which was huge and impactful. The "center of thought" in the text processing problem area moved hard to web development. And so the ideas about what needs to be improved or changed rapidly centered themselves around "Things PHP Did Badly". And that begat Ruby and Node, not a fixed-up Perl.
Perl remained (and remains!) eminently useful in its original domain of Unix system automation glue and ad-hoc text analysis. But it was denied a path to the future by PHP, and by the time PHP was itself replaced it was too late.
Finally everyone else (python in particular) sorta caught up to the "clever systems glue" feature set, and the world moved on entirely. Perl is mostly forgotten now except by those of us who lived it.
PERL tripped over it's own feet (too clever, line-noise, unmaintainable).
Java(TM) being "guaranteed to be business-like" sucked the serious use cases away.
PHP was easier to grok, had "editable man pages" (ie: comment forum attached to each built-in), and didn't have "slow CGI overhead" or "FastCGI complexity".
Python was waaaay easier to read/write/maintain, and was a serious alternative (except for trickier process-control integration, you couldn't just "$XYZ = `ls -al`" like you could in perl).
...and then "PERL6 will be gloriously filled with rainbows, butterflies, will be backwards incompatible, and will be released Any Day Now(tm)" sucked alll the oxygen out of a developer investing in perl.
By the time nodejs became another contender for server-side languages, there was no place for PERL as it's effectively become kindof a COBOL for unix systems. Don't touch it if you can avoid it, and it requires expensive, difficult-to-find specialists to maintain it if you need to.
> Also, even if Perl 6 had never happened the way it did and instead we'd just had smaller evolutions of the language in major versions, I think usage would still have shrunk over time.
Maybe. I mean the whole point of 6 was to modernize perl.
Perl needed efforts like 6 to happen, but it needed them delivered in smaller chunks over the years rather than as a big decade long "And now 6 is here".
Java learned this lesson after Java 8 and 9 which took multi-year effort to deliver 1 or 2 big changes to the language and the JVM. Now Java has multiple efforts in flight which have trickled in over the years (tickling me as a dev). Every 6 month release is a little better which makes the multi-year efforts seem all that much more worth it when they land.
My impression was experienced Perl programmers took pride in making the smallest code possible, all in one line.
At my company they really locked in the project being dead if the original contributors left.
Perl propped up regex (JavaScript regex is based off of it), so I get the impression Perl practitioners tried to make all the code regex-y as possible as a cultural thing.
There was a regular feature in the perl community for 'golf' or 'crazy one liners' but almost no one used that shit in any actual code that left their user directory.
I remember the Perl art competitions, where you would write Perl code that would run and actually do something, and would be ASCII art at the same time. Obviously, lots of camels ;-)
Not to mention that trying to understand existing Perl by asking the community 'what does this do' or 'how does this work' often (in my experience) resulted in 'RTFM' or 'man perldoc' rather than someone taking any time to actually answer the question, whereas other communities were more welcoming and helpful to each other. That made it difficult to learn Perl through other people's code compared to other languages.
I think that depended on where you were looking and how you were asking.
My main source of support back when I did much Perl (late 90s, early 00s) was usenet, and while some groups were very snubby and elitist others were very helpful and encouraging for a young budding programmer.
I started programming in the late 90s using Perl as my first "real" language. When I first saw some Python code (2.3 if memory serves), I found it much easier to understand. Not necessarily easier to write, but diving into a Python codebase 6 months later was a lot easier than doing the same than with Perl. Purely subjective, but I was far from the only one, even if quite a few people at the time preferred Perl.
Later, when the Web really took off, running PHP 4 was much easier to get going than either Python or Perl, so a lot of us went with that.
And yeah afterwards JS with node.js in particular. The millions pumped into it by Google certainly helped.
There was also a time a bit later with Ruby getting really popular. Not just for new projects, I heard of some codebases migrating from Perl to Ruby, when the writing was on the wall for Perl 5.
Go, I think when it became popular not many people were still using Perl. Also not really something you would use to bang out a quick script with. Probably more of a competitor to Java.
As for me, back to Python as my bread and butter. Probably haven't touched Perl in 20 years at this point. Looks like gibberish to me now...
True. Adding to these. Perl6/Raku suffered from the second system effect. Described in the Mythical Man Month. Larry and company were over confident with their previous success.
Perl was pretty much first in the wave of interpreted languages from the late 80ies and 90ies. It set the bar on what to expect from such ecosystems.
But being the first meant it got some oddities and the abstractions are not quite right imho.
A bit too Shell-esque, specially for arguments passing and the memory abstractions are a bit too leaky regarding memory management (reference management fills too C-esque for an interpreted language, and the whole $ % @ & dance is really confusing for an occasional and bad Perl dev like me). The "10 ways to do it" also hurts it. It lead to a lack of consistency & almost per developer coding coding styles. The meme was Perl is a "write only language".
But I would still be grateful of what it brought and how influential it was (I jock from time to time how Ruby is kind of the "true" Perl 6, it even has flip flops!).
In truth, these days, I feel the whole "interpreted languages" class is on the decline, at least on the server. There are a lot of really great native languages that have come up within the last few years, enabled in large part by LLVM. And this trend doesn't seem over yet.
Languages like Rust, Swift, Go, Zig or Odin are making the value proposition of interpreted languages (lower perf but faster iterations) less compelling by being convenient enough while retaining performance. In short, we can now "have the cake and eat it too".
But the millions of lines in production are also not going awywhere anytime soon. I bet even Perl will still be around somewhere (distro tooling, glue scripts, build infra, etc...) when I retire.
Anyway, thank you Perl, thank you Larry Wall, love your quotes.
> And Go came along and provided an aggressively mediocre but very usable
See, that's one of the things lots of people who enjoy Perl and/or Ruby in the comments around in this thread don't quite grasp: some languages require programmers possessing a somewhat special state of mind to read and write productively, and some languages allow pretty much every mediocre programmer to read and write, and still produce a manageable program.
The other thing is the information density. In my experience, most people after graduating high school have experience with reading mainstream fiction and school textbooks, and those things you can half-skim/half-read and still get out most of the meaning. Then those people hit the college-/university-level textbooks and screech and crash because those books, you have to read them sentence by sentence; not everyone can get get used to it (or even realize they have to do that in the first place). And similar observations hold for programming languages: Perl and APL are just way too dense compared to Go and Python; if you're used to reading code line-by-line (skimming over half of them), then it's really bloody annoying to switch to reading sigil-by-sigil (as for writing, well, we all know that typing speed was never really a bottleneck for programmers).
My main complaints about Go are not that it needs more obscure syntax. The biggest problem with Go is basically that the core of the language's syntax is special, and only accessible to the compiler. This goes hand in hand with the language not offering generics out of the gate. This means that things like slices, maps, channels, etc. are all special. You cannot implement anything similar that uses the same syntax (even now that generics exist).
This lack of flexibility means that it's impossible to experiment with replacements for built-ins, and the lack of generics out of the gate meant so many things were simply impossible (like useful iterators).
Compare this to Rust, where almost everything like this is just a trait. If you want to offer a map replacement, you just implement the Index and IndexMut traits.
Overall, I don't think Perl is the best language design. It has some interesting ideas. Go is _also_ not the best language design. Is Rust the _best_? No, but it's better than both Perl and Go, IMO.
Many of us see that as an important feature, and a smaller set of people aren't too happy with the generics introduction for example. Or the recent iterators stuff they have added.
It makes codebases touched by a lot of people an absolute breeze to understand. There's no clever generic data structure/soup of traits/clever conditional types I have to understand from scratch. Everything is the same old boring maps and slices and for loops, nested sometimes. And functions mostly always return 2 values. There is no map/filter/anything. The name of function usually betrays the types. "getUserPreferencesBatch" is most likely a `func(userIDs []UserID) map[UserID]Preferences, error`. There's <1% chance it is anything else. People also tend to avoid relatively complicated datastructures like trees unless they are really really necessary. So you get boring, completely predictable, 70% optimal code.
Even when discussing implementation, people think in simple terms which leads to really simple implementations in the end across all team members. It basically makes drumming KISS into everyone really easy.
Now some people go all clean code or make functional wrappers and such, and that destroys all that's good in go.
But I don't want to read your cute custom hashmap code. Go really shot for the stars with its primary design goal of uniformity. The hashmap you're using is the same one I'm using, is the same one any random Go repo on Github I open uses. The value of this is immense—I instantly feel right at home, I know the exact semantics you're using—we're speaking the same language.
To wit, I would argue that Go didn't go far enough in restricting the user and certainly did not pick the right features to include. I don't think it's clear at all that had go shipped with sum types—enabling better error handling—and iterators, more built in generic data structures, and higher level abstractions around its concurrency, but no generics at all, that we wouldn't end up with a far better language. A more restricted one, with even less room for anything custom, but a better one.
I wouldn't call making the right decision confused. It clarified and justified their desire not to use Perl. Only a confused CTO/VP Eng type would choose to use Perl in spite of all its entrenched disadvantages and much better more popular alternatives.
I was just saying that they were confused about what was going on with Perl because if the Perl 6 effort. I don't think that they were confused or wrong in their decision making.
Before Perl, there was no scripting language that could do systems tasks except maybe shell and tcl, but that's shell is an extremely unpleasant programming experience and the performance is horrid, and tcl's string-based nature is just too weird.
Perl gives you something more like a real programming language and can do shell-like tasks and systems tasks very nicely. Compared to what came before, it is amazing.
But then Ruby and Python came along and checked the "real programming language" box even more firmly than Perl while retaining the shell/systems angle. Ruby and Python were better than Perl along exactly the same axis as the one on which Perl was better than Tcl and shell.
IMHO Python killed both Perl and Ruby. While Ruby is more alive than Perl it's nowhere near as popular as Python.
I like Perl and used it professionally for year and vaguely remember probably around 2010x relatively massive Python evangelism (lots of articles, conferences, lots of messages from Python adepts on forums e.t.c). One of talking points (no longer needed nowadays) was that Python is backed (sponsored) by Google so Python will be successful and you should not worry about it's future and also if you will choose Python you will be successful (as Google is).
I think Ruby has declined because Rails was its selling point, but Rails was optimized for the world of HTML templates. Once you're writing JavaScript-heavy frontends and mobile apps, Rails isn't giving you much that you can't get from Python or server-side JS.
A few people started using Ruby for command line tools[1] but the community was very focuses around rails. Also Ruby isn't usually part of the standard OS install. So Ruby stayed stuck in it's Rails niche.
For me, this is why python took off. People wanted that lucrative job or receive the reflected glory of a winner, so y'gotta learn python. The rest is just post-hoc justification for why you made that choice passed on as "this language is better because of blah..."
A lot of the justifications don't stack up against serious scrutiny, but are accepted as gospel.
In previous life, worked on large object-oriented Perl. There was a difference between good Perl and the Perl in messy scripts. Good Perl was nice to work in but required discipline to keep organized.
I wonder if there was an earlier point of Perl's demise. Perl 5 came out with flexible object-oriented features, but it took years for packages like Moose to come out and make it nice and usable.
I always thought one of the best and worst things about Perl was the fact that you could build something like Moose with it.
But the bad side was that by the time someone was clever enough to invent Moose, all sorts of other bespoke object systems had been invented and used in the meantime, and your CPAN dependencies used every single one of them.
Good luck getting any two people to agree on a sharp line between programming language and scripting language. Perl seems to swap sides depending on the year people are arguing about it.
Entire enterprises ran/still run on Business BASIC and Delphi code. Billion-dollar fortunes have been made on such code. Those languages are used for serious things all the time.
By the time Perl 6 was around, Perl's lunch was already eaten by Python. Only a few table scraps left. Perl 6 would have had to be a better Perl 5 and a better Python 2 to win.
Python came with better batteries and better syntax. It allowed producing code you could read and understand a week later. Perl I found was a write-only language for me. I went back looking at my old Perl code and I couldn't decipher it without some effort.
And Python became popular not just because it was a better Perl, but it attracted folks who used Java and C++. CPU speeds were getting fast enough that you could actually do file and network IO at acceptable speeds without all the `public static void main(String[] args)` and `System.out.println(...)` boilerplate, but still had all the object oriented bits like inheritance and composition with which you could go crazy with if you wanted.
Personal anecdote in support: my first job out of college was at a data-analysis company, where my task was usually to write one-off scripts to extract data from various data sources and massage it into the format the analysts wanted for their spreadsheets. I wrote most of those scripts in Perl at first, with the odd Bash script here and there. Then one of my coworkers said "Hey, if you like Perl, you'll love Python". I learned Python (2.1 was the most recent version at the time, which tells you how old this story is) and almost immediately switched over. All my new one-off data-extraction scripts from then on were written in Python (though still with the odd Bash script here and there).
When I was doing undergrad CS in 2006, we had a choice between Perl and Python for our scripting assignments. As far as I know, no one chose Perl. It's comparatively a huge pain to get ramped up on, and the promised payoff is that you get all these implicitly stateful sigils that let you write contest-winning one-liners. But by the early 2000's, the culture was getting up to speed on obvious-in-retrospect principles like "avoid global variables" and "you should give your variables names that someone else can understand", and even as students we could all see that Perl wasn't going to be the future.
I chose Perl first. At that time around early 2000s it was the more popular. I liked how my scripts were short and compact but then I I had noticed that I couldn't understand what I did week or so later. The "write-only language" joke was kind of true for me. Then remember finding Python and rewriting all my script in Python and have been using it ever since.
> Perl 6 would have had to be a better Perl 5 and a better Python 2 to win.
Don't sell perl 6 short. I am using perl 6 for significant projects now (after a career of perl 5) - and it's fundamentally different. I describe it as perl to the power of perl.
For me, expressiveness is fundamental. And perl 6 gives me that.
Perl 6 is simply suffering from python being everywhere. And perl 5 was always easy to lampoon as "line noise". It's a stupid quip, but it leaves a mark on new programmers. You don't even need to read the course and you can already have an opinion. Stupid kills? And then perl 6 doubled down on that anyway. Then I doubled down on that ALSO and I get to use (carefully chosen) unicode symbols in my line noise :-) So there.
> For me, expressiveness is fundamental. And perl 6 gives me that.
I saw Larry Wall at one of the conferences. He talked a about Perl 6 how it was progressing and such (it was before it was renamed) and year, expressiveness what stuck out. It certainly has lots of nice features, too. But at least for me, I realized with Perl 5 I wasn't smart enough for it. I would be lured by the clever short expressions and then sometimes later look back and had no idea what I wrote.
Larry is a great person, btw. During lunch at the conference sat at his table and he was very approachable and warm. I don't remember what we talked about exactly just that it I liked how down to earth and nice he was.
> But at least for me, I realized with Perl 5 I wasn't smart enough for it.
I feel like you but I love it: I am not limited by the language. Not by perl 5 and not by perl 6: When I am willing, I can dig deeper and find more to work with. When I am willing I can try and follow presentations or books by Damian Conway, Mark Jason Dominus, etc and I can get new ideas and inspiration. I can always learn more about this fundamental tool that's at the center of what I build. The tool challenges me in a good way. It does not slow me down. It does not limit me. If anything in there is going to limit me, it's going to be my own brain.
And perl does that without tripping me. Because in perl, the intuitive way is one that's not likely to hurt you. While if you know better, you can work with the more elaborate, deeper features.
I hate it when I have to use a language that constantly limits me. It has happened. I am not always free to choose the programming language or platform. For some, it's so frustrating that I charge more. And it's still frustrating.
I have exactly zero functions that are written in both. So comparison is just intuitive:
My current projects make extensive use of numerical functions AND of regexes and grammars. Both used extensively. I am very satisfied with the performance on both aspects. It does the job. And there is no question that for the regexes and grammars, what I have goes FAR beyond what I ever dared to run in perl 5. Performance is good, including on this stuff that I feel would have been pushing perl 5.
Still, I write for expressiveness. It matters to me how fast I can write. And I am NOT satisfied with "searching through the doc". That's the main sore point for me. The doc is very good but online-first and local... eventually. So I am stuck using an online search function... which constantly falls short.
Perl exploded because it was the easiest, richest ecosystem available to plug into CGI and the web.
PHP & Ruby & Python then collectively covered the same waterfront whether you wanted “easy” or “fun” or “simple”.
And I would propose that PHP attracting the developer cohort who wanted “easy” and Ruby/Rails attracting the developer cohort who wanted “fun” were each individually more damaging to the Perl ecosystem than Python.
Agreed. In grad school, I used Perl to script running my benchmarks, post-process my data and generate pretty graphs for papers. It was all Perl 5 and gnuplot. Once I saw someone do the same thing with Python and matplotlib, I never looked back. I later actually started using Python professionally, as I believe lots of other people had similar epiphanies. And not just from Perl, but from different languages and domains.
I think the article's author is implicitly not considering that people who were around when Perl was popular, who were perfectly capable of "understanding" it, actively decided against it.
PHP contributed hugely for me. I was writing a lot of Perl for web apps from about 1996 to 1999, when PHP really took hold and was an improvement in almost every way, right down to including PCRE regex functions. Perl felt clumsy compared to PHP, especially for MySQL and other relational DB stuff. PHP was built for the web.
To me Perl was just Weird, to no particular end. Not the kind of mind expanding Haskell/Prolog/Lisp weirdness that opens up new possibilities. It just does roughly the same things as every other language, but everything is done slightly differently due to evolving out of the primordial soup of bourne shell and AWK filtered through Larry Wall's brain.
Perl and Python were similarly powerful and useful languages, but I could learn and start producing useful code in Python after reading an hour long tutorial. Perl took an order of magnitude longer, and remained more awkward to use just due to the Weirdness. There was a momentum building in the early 2000s toward competitors like Python and Ruby that were seen as less crufty and more modern.
Perl's developers seemed to agree, since they cooked up their own competitor to Perl, an entirely different language confusingly called Perl 6. The coexistence of Perl 5 and 6 made the Python 3 transition look like a cakewalk -- at least it would have save for Perl 6's almost entire failure to exist for over a decade after its inception. It produced lots of constantly churning specs and blog posts about register based virtual machines with native support for continuations or whatever, but no implementation of a language that anyone felt comfortable using for any real development. Meanwhile people kept using the ossifying Perl 5 for existing applications, and gradually transitioning away as they were replaced.
Also PHP overtook it for the "just FTP a script to $5 shared hosting and make a webapp" use case.
I agree, and the blame for its weirdness can be laid directly at Larry Wall's feet, because Wall wanted a language that allowed for cleverness, suprise, and ingenuity. He was never happier than when someone would come up with a completely new way to do something. For Wall, programming was less about coding an outcome, than it was about speaking a particular language (and ideally, writing poetry in it). And it was very successful in this way, and fit reasonably well with the high-knowledge users/environment of unix in the 90s.
It's just that Wall's vision was incompatible with general purpose languages used widely by a wide range of knowledge and skill amongst its users, and as unix/linux opened up to that wider range, better general purpose alternatives were chosen. Having to learn to be a poet to be a good coder was too high a barrier.
> Wall wanted a language that allowed for cleverness, suprise, and ingenuity. [...] Having to learn to be a poet to be a good coder was too high a barrier.
To me this just sounds, umm, pathologically eclectic.
This claim always seemed bizarre to me. What kind of drugs do you think a layman would think you were on if you showed them a typical Perl program and asserted how "human-like" it was? Even if you tried to follow-up and explain it: "No, no, see this bit means open whatever file stream is specified in the command line, as long as it starts with a letter between 'A' and 'F' that can be either upper or lower case, and is followed after any random characters by at least 3 digits in a row. Then this next character means.... See? It's just like I'm describing it to you!"
2. Ruby (on Rails) taking over the workhorse task of serving up dynamic content that Perl had owned before then
3. Python completely dominating the utilitarian scripting/programming world in nearly every niche
Why did this happen? I was a work-a-day developer working in Perl v5 when this transition occurred and from my perspective and recollection v6's meandering development cycle -- which didn't really address the issues of the broader Perl community was the primary choice. Perl 6 was developed in a way that didn't address the broad concerns of the Perl community, and expected people to make a wholesale switch to what was effectively an entirely new language anyways. It forced people to go out looking and what they found were either stronger solutions to specific domains (Ruby on Rails) or a nicer language than what was being proposed (Python).
Where Python really excelled at the time was that it looked and worked very much like the pseudocode that was going around at the time, and had an opinion about how you should write your code. Perl is wonderful to write in, but in many ways is too expressive and permissive and it resulted in an ungodly mess that could be hard to maintain. Perl 6 simply leaned into that problem rather than encouraging a cleaner approach.
I never liked Python much, but damn if I couldn't argue that I was much more productive with it than Perl in the end. Which was weird because when I was really hacking in Perl I could write code almost as fast as I could think giving a kind of illusion of productivity. But Python was easier to integrate into a coherent team development structure and actual productivity is more important than feels.
I miss working in Perl. But I knew it was really finally dead when I was giving tutorial classes to new bioinformaticists who were being given old Perl codebases to update and they were getting through school without learning the language.
I would say PHP instead of Ruby was the big hit on Perl for web. It sat nicely in Apache and made replacing old cgi-bin much easier. It also had the philosophy and syntax heavily inspired by Perl
Python was indeed the scripting replacement. I would say it won because of its philosophy on simplicity and explicitness. Perl v5 suffered heavily in complex projects because the language itself was too complex and often cryptic
I think you're right about the significance of PHP.
PHP kicked Perl's butt in the shared web-hosting environment.
You could do amazing stuff with mod_perl, but it was not possible to run a shared host with mod_perl without exposing every customer to every other customer's code. You could still do cool stuff with vanilla CGIs. Perl was practically synonymous with CGI back in the day. Once you grew past what a simple CGI would handle, it suddenly got a lot harder and a lot more expensive.
Meanwhile, PHP had simple Perl-like syntax and ran nicely in shared hosting. Better yet, you didn't have to choose from one of the 400 different Perl templating systems. No need to choose between TemplateToolkit, HTML::Mason, or Embperl. You just used the standard, built in templating.
PHP won because it was worse, you didn't have the power or choice Perl provided, but it was more than good enough and it was cheaper to grow with.
On Perl vs Python:
- Perl was weird and proud of it, it promised creative power and flexibility
- Python promised regularity and clear rules
- Perl tried to make hard things easy
- Python tried to make routine things routine
- Perl had weird primitives that let you build whatever magical OO nonsense you wanted.
- Python supported writing glorified struct OO that was fashionable at the time
- Perl was difficult to integrate with C libraries
- Pyton integrated much more easily with C libraries
That being said, I like Perl much more than Python. Using Perl still feels magical, even if some of the syntax is odd. Using Python feels like I have my shoes on the wrong feet.
There's more than one thing that "killed perl" (I still use it almost every day.)
But I think the main thing that made it long term non competitive were a series of bad design choices all the way back to perl 4 or even 1.
Namely:
- the need for sigils
- weird sigil rules where the 0 element of @x is $x[0] not @x[0]
- auto flattening, ex. (@a, @b), and hence the need for manual reference management, as in (\@a, [1,2,3])
- lack of a native object system, and widespread repurposing of hashrefs as objects, with awkward field syntax $x->{foo}
- awkward function argument syntax: my ($x, $y) = @_;
These things add up, and both JS and python showed that all those can be done much more smoothly.
Another thing that counted at the time, is that PHP came out with a slightly worse language, but a super beginner-friendly approach to html templating and request lifecycle: you can just mix php and html in the same file, and the entire runtime environment is nuked at each request. The result was that php replaced perl for an entire generation of web devs in the early 2000s.
- weird sigil rules where the 0 element of @x is $x[0] not @x[0]
'@' and '%' indicate containers, while '$' is a scalar (which containers can contain). So '$x[0]' is referring to a scalar within the '@x' container. If you operate on a container, like 'push @x, 2', it uses the container sigil.
I guess "weird" triggered me a bit, heh. I know it's subjective.
To get Perl to work with apache (the most used web server for a time), there were two options: the not-so-complicated cgi script which gets executed from scratch on every request, then there was mod_perl which required a lot of tinkering with apache configurations and writing your code in a different way.
Even with those two options, you can't just write some code in a page and execute it without some sort of itermediate code.
Thats why php became so popular, perl coders could pick it up in a day ($ and all) and all you have to do is write .php files to a server - with the bonus that you have a rudimentary templating system built-in to php.
I vividly remember the first time a friend showed me PHP in the late 90s. You're saying I can just write a script that generates HTML and throw it in /foo/index.php and that's the whole thing?
It's wild that right up until Rails got popular, we were writing code that served billions of requests off of homebrewed MVC-ish PHP frankenframeworks.
> mod_perl which required a lot of tinkering [...]
Here we used mod_perl all over the place and it was glorious. It did take understanding how to use it - well, yes - same as the rest of perl (or apache for that matters). But it was so well integrated! I still miss it.
"Picking it up in one day" is not a criteria for professional deployements.
> Here we used mod_perl all over the place and it was glorious. It did take understanding how to use it - well, yes - same as the rest of perl (or apache for that matters). But it was so well integrated! I still miss it.
Most people, including small businesses, used shared hosting providers back then, and none of them supported mod_perl, while most of them eventually did support mod_php. That's why PHP came to completely dominate the market for self-hosted (or hostable) web applications, like phpBB, Drupal, and WP--writing those in anything other than PHP after mod_php became available (but before AWS) made no sense. PHP was at least as ubiquitously supported as Perl, and through mod_php (avoiding CGI's overhead), much faster.
Once mod_perl existed (it was late, after lots of CGI perl) - I feel that my clients and I never had significant difficulty in finding providers. PHP was all over the place - it felt - more because there was demand. But there was enough demand for mod_perl that it was always there when we wanted it. We never had to really hunt for a hosting vendor.
> I feel that my clients and I never had significant difficulty in finding providers
Yes, for professional uses. But we lost the next generation of devs. You could put PHP on any shared webspace and people started messing with it and from that messing, the next generation of open source PHP programmers came.
If you wanted to throw up a personal project using mod_perl you pretty much had to pay for a hosted box. At least once people realized how insecure it was to run shared code on a mod_perl host.
You could find hosts but it was comparatively expensive.
Plus it was a huge pain in the neck to do things like install the modules you needed on a shared host.
This was a huge barrier to entry and it made things unreasonably difficult. Meanwhile PHP was very low friction. And at the time, so many new people were teaching themselves web development to scratch itches and solve problems that these barriers were a big deal.
Which sucks, because mod_perl was amazing, beautiful tech.
> At least once people realized how insecure it was to run shared code on a mod_perl host.
People realized this immediately, given how much mod_perl exposed Apache's guts to script writers (so they could write modules in Perl--a feature few asked for, and fewer used) and how tightly coupled the two were, so much that calling Perl's humble 'exit' built-in became a notorious footgun (until, IIRC 5.6), terminating the underlying Apache process itself.
My hypothesis is that as the volume of Perl grew, it became more and more apparent that it wasn't a good idea to write new projects in Perl:
- Perl's fascination with punctuation makes it hard to google for stuff, since search engines strip punctuation. In an era of RTFM and grep, maybe this is okay, but puts the language at a substantial disadvantage vs languages that use more prose than punctuation
- The distinction between scalar vs array context is subtle and feels somewhat pointless if you learned a language like C or JavaScript first. C has no overloads but manages to work fine, and other scripting languages like JS or Python let you branch on the runtime type of variables explicitly. Why bother with array context?
- Similarly, people got used to having named function arguments in their function signatures. Maybe in an era where most code was either compiled (and had named function args), or was stringly-typed and scripting like Bash, Perl feels like more of the same. But once we started getting decent scripting languages that had named function args, it became a real pain to repeat basic stuff like "assign parameter 1 to variable $name, assign parameter 2 to variable $age" in every function. I wish shells would bite the bullet and figure out a way to adopt them.
Overall, our industry is moving towards larger scale and complexity, and at larger scales, reading and maintaining code is more important than writing code. Perl's language design choices are all balanced for 1-10 unix wizard authors having fun writing small scale scripts. Compare it to Java, the Anti-Perl: today scripting languages like Python, JavaScript are getting closer to Java or ML with compile-time type checkers and sophisticated type systems. Few new or existing languages are getting similar to Perl.
I don't think Perl 6 had anything to do with it. I wrote a lot of Perl5 in college, and didn't particularly want to write any more Perl5, or adopt Perl6.
Already in the very early millennium, jokes like “Perl is an explosion in an ASCII factory” were going around the computer-nerd community, while several publishers were putting out affordable and fun and engaging books to learn Python. No surprise that Perl quickly declined in popularity for scripting. It has been amusing to watch the continual waves of reawakened interest in awk, while Perl seems to remain perennially marginalized now.
The value proposition for AWK is very different from Perl. AWK is a tiny language that can be learned quickly, and it's ubiquitous: a hard requirement for even the most bare-bones POSIX environment. AWK is on your machine already; Perl may not be. If you have to install Perl, you could just as easily install any one of hundreds of alternative scripting languages.
AWK scripts don't have any kind of dependency management features, so they naturally lend themselves toward being freestanding and self-contained. Perl, on the other hand, has a massive package ecosystem with transitive dependencies and widely varied quality and design aesthetic, amplified by the baroque design of the language. AWK is as close as a language can be to immune to dependency hell.
When Perl was new, perhaps many people saw it as "a better AWK", but I suspect most of the newcomers to AWK today don't see it in relation to Perl at all.
For me, Awk is this awesome tool for quick and dirty 1-3 line scripts to transform textual information. I hardly use it, but when I do, it serves its purpose well. It's also relatively easy to read and understand.
I remember learning most of Awk from a long, single web page that appeared to come from one of the official authors.
Perl died because the other languages are better. IMO, Perl was a quick solution to a need; but it has since been eclipsed by modern languages.
I was in college 1999-2003, I did PHP in an internship, and then later did some Perl in one of my classes.
Perl (in my college class) was so incomprehensible that I decided that I would avoid it. I've never applied to a job that uses Perl, and never responded to a recruiter that was looking for a Perl engineer. I've never had to use it at work, and fortunately I've never worked with anyone who wanted to use it.
I think it's best to think of Perl as a transition technology.
It's been discussed before, but Python just seemed more straightforward to a lot of people. It had a built-in object oriented model as well when that was the rage instead of the weak default one and dozen modules on CPAN to do object oriented programming. There was generally one way to do something and that was easier to learn than TIMTOWTDI.
"There should be one-- and preferably only one --obvious way to do it."
It also came with batteries included, which really lowered the learning curve.
Perl was well known for being a pain to read months after you wrote it. Most Python code in those days was readable by people who did not even know Python.
When I started my job in 2010, I took a class at work on Perl. I had done some Perl years before and had grown sick of it, but I thought I was just doing it "wrong" so I thought the course would tell me how to code in Perl "properly".
Nope - I'd been doing it "right" all along. I just hated the language. At the end of the course, I told the instructor (a graybeard) that he should just use Python, and that one day I'd teach the Python course and he should attend. He scoffed at the notion: "Languages will come and go, but Perl will always prevail!"
I never did teach that course, but I bumped into him about 7 years later. He had completely (and willingly) abandoned Perl for Python, and was a big Python advocate.
One of Python’s killer features is how easy it is to find a Python library wrapping some native code library written in C or Fortran. Those used to be notoriously difficult to write for Perl.
I was writing a comment asking if it was really easier. Then I took a look at Cython. Yes, this looks easier than Perl's XS, which I have some experience with! There are ways to do something similar in Perl these days, notably https://metacpan.org/pod/FFI::Platypus. But these are relatively new (starting in the 2010s) compared to the history of Perl, and Cython goes back to the early 2000s.
Somewhere in the continuum from SWIG through XS and on to Platypus there are also the Inline modules these days. They allow one to put inline sections of other languages into Perl code the way many language tools used to allow one to inline assembly into C or Pascal code.
There are some of these modules for other languages than those listed here, a lot of them as high level as Perl (including Raku and even another Perl system for some reason).
True. For whatever reason, these never displaced XS. For wrapping C libraries in particular, it's not clear to me how much Inline::C helps with this. You're still stuck using a lot of Perl C API calls, AFAICT, which I think is the biggest challenge of using XS (I still have nightmares from trying to figure out where and when to add `sv2mortal` in my XS code).
One or two calls into a library with a simple C interface isn’t that bad with Inline. You just use Inline to handle the Perl to C to Perl part, and actually do the interfacing in the inline C. It’s a lot more mess if you’re doing complex things and bringing complex data structures back to Perl, or having Perl make a lot of intermediate decisions and doing a lot of round trips. So if you use Perl to get the data ready to pass in, pass it in, do all the work in C that you need the library for, then pass the results back to Perl once it’s not terrible.
I’ve tried not to get into XS, so I couldn’t really compare.
Using Inline::C with your own C code in places where Perl is too much overhead is certainly easier than wrapping a complex existing library with a lot of interactions across the boundary.
FFI::Platypus or something like it really is the way of the future though for existing C calling convention libraries in other languages.
TIMTOWTDI broke down with trying to do OOP in Perl. You could either bless a hash, or use a meta-object framework (moose?). You could end up with hierarchies of different types of objects with their own behavior.
I was a Perl programmer, and I looked down my nose at PHP. Silly me, then and now
Why did PHP, an objectively a worse language, win?
Rasmus Lerdorf said in a quote I can no longer find, it was modperl vs. modphp for Apache.
Modperl was, typically for Perl, very comprehensive and allowed access to all the Apache processing hooks
Modphp was, typically for PHP, just enough to speed up rendering so only allowed access to the barest minimal set of hooks
Modperl, so much better (I can hear myself say 30 years ago)
But at the time most websites, by count not by traffic, ran on shared hosts where the system administrator gave you access to software. If they installed mosdperl you would be able to intercept, read, and change traffic for all websites hosted on that machine
Modphp, not so.
So PHP was widely available to the pioneers in the day, people scratching together a little web hosting business and growing . Perl was not
Not enough on its own to kill Perl, but an important nail in its coffin
I learned and used Perl professionally from around 2005-2015 and experienced first-hand the ossification, fear of change, and lack of innovation in Perl 5 development. It seems all the talent and effort started being wasted on making Perl 6 the bestest, most elegant, most useful programming language in the world. Just seeing the neglect of Perl 5 kept me from ever considering Perl 6 and motivated me to move to other languages.
My experience of working with Perl as a primary language from late 90s to today: Perl was dead long before Perl 6/Raku was a real thing. By the time that happened it had already lost massive ground to PHP, Python, Java, etc.
PHP had replaced CGI as the easiest way to get code on a webserver, Python and Java were easier to read and understand, easier to structure large systems with, and generally easier to use. Ruby came along and MVC frameworks became the thing for complex web platforms.
Meanwhile Perl was sorta keeping up, the "Modern Perl" movement helped dispel myths about "write only" code, things like Moose, DBIC, Catalyst, Mojolicious, etc meant you could write pretty modern stuff with it. But the community was smaller, fractured by Perl 6 and dominated by some ahem divisive characters which made it intimidating for newcomers, and it just slowly died from there.
By the time Stack Overflow came along it was easy to see that other languages had vibrant communities surrounding them and for me it never really recovered.
About a dozen years ago, I noticed that the young all seemed to know Python, and did not seem to know Perl. Given that they would be maintaining such code as I wrote and was worth keeping around, I moved to writing in Python. Now when I write Perl, I do silly things like forget semicolons.
Perl can be very well written. I deeply regret not encountering Perl Best Practices when it came out.
I think it is due to the fact that Perl has some confusing bits like those variable prefixes ($@%), the lack of function arguments (I know that this has changed recently), not really great error handling, etc and so people started using languages which seemed easier to use like Python.
The variable prefixes are just the tip of the iceberg. The real problem with those prefixes is that they, themselves, are context-dependent on attributes associated with the underlying data type at run time. So you can find yourself in a situation where the behavior of the syntax differs in ways that are difficult to control for during development.
Strongly agree. A language which has something like “wantarray” as a first-class feature is semantically…unique, at best, probably more like “flawed by design”. All the oddness with typing and sigls descends from that.
Same for autovivification. Insane feature. Useful for some problems but causes many more.
Which is a shame, because perl5 semantics had some nice features too! But there’s only so much you can do with a structure whose foundation is so wacky.
I remember trying to use the new "reference" feature (when it was new), with "blessing" and so on and so forth, to try to create real data structures, and finding in some way or another that it was just not regular. I can't recall the details, but something along the lines of a feeling that the syntax worked differently for, say, the top level of a tree (or first index of a multidimensional array, etc.) vs the rest of the structure.
In the main, the sigil refers to the type of the eventual value, regardless of what contains it. The tl;dr is that you mostly use `$` unless you're wanting more than one value, or to dereference (when you use the sigil for the type of reference). Some examples:
@array = ("a", "b", "c", "d"); # @array contains scalars
$array[0]; # use `$` for a single element
@array[0..2]; # use `@` for an array slice
@array = ( [1..5], [6..10] ); # @array now contains array references
$array[0]; # use `$` still because references are scalars
$array[0][1]; # still use `$` even when going multidimensional
@{ $array[0] }; # use `@` to dereference an array ref to array
%hash = ( a => "b", c => "d"); # % for hash of key/value pairs
$hash{a}; # `$` because you're getting a single scalar
@hash{"a","c"}; # `@` because you're getting an array of values
Where things become a bit less regular is the difference between reference and non-reference for hashes and arrays when they are top level. At the top level, you need a `->` but that becomes optional at levels below (because at levels below, they have to be references).
$arrayref = [1,1,2,3,5]; # `$` because we're creating an array reference
$arrayref->[0]; # `->` because top level
$arrayref = [ [ 1 ], [ 2 ] ]; # arrayref of arrayrefs
$arrayref->[0][0]; # no second `->`
$arrayref->[0]->[0]; # ... but you can use it if you want!
And then there's stuff like getting a slice out of an arrayref
$arrayref = [1,1,2,3,5];
$arrayref->@[0..3]; # oh dear. get a real array with an `@` but not at the start!
> Where things become a bit less regular is the difference between reference and non-reference for hashes and arrays when they are top level. At the top level, you need a `->` but that becomes optional at levels below
Yes, that's probably what I was remembering. Thanks for the exposition.
I never understood why Perl has all these crazy features. It feels like someone going "hah it would be funny if it worked like this..." but actually really implementing it.
People always said "it's because Larry Wall is a linguist!" as if it explains anything!
You always go from "this is neat" to "...but why" quickly with perl.
Yep. Perl the first language I ever used to professionally do something approximating "real programming" (as opposed to one-off scripting). And then I learned Python and never touched Perl again ... at least at the time, to my very inexperienced self, it felt like an improvement on every single axis.
In retrospect, probably 90% of my enthusiasm for python over perl was just "if you use python, you never have to think about variable sigils ever again." That and `string.split()`.
Perl originated from shell programming and inherited some of its patterns. If you ever looked at a bash script using arrays you will immediately recognize "@" to access the array as a whole and the switch to the "$" sigil to access a single element from that array. Perl was designed to make it easy for shell script writers to pick it up.
Yes, that's almost as old as some currently-hyped programming languages. But it's quite new compared to the natural behaviour of some developers (a fact that I used to find surprising and now just find disappointing).
Comparably: today, in the Python world, people are praising tools like uv because now they "don't have to understand virtual environments". And continuously since the introduction of PEP 668 three years ago, people have been grumbling about the expectation to leave "externally managed environments" alone. But uv still uses virtual environments; and `venv` has been in the standard library since 2012, and the third-party `virtualenv` that it's based on has been available since 2007.
I still use perl. It's my go to for string parsing (think pipe log file, do something with it and send it to stdout). It's also my go to for anything that I still want to work in 10 years.
What killed Perl for me was readability, long before Perl 6/Raku. I was an Awk programmer from way back, so took to Perl quickly once it was available. Then in the late 90's I wrote a utility program in Perl that generated some nice HTML documentation for me from some kind of input format I no longer recall.
A year later I tried to use that script on another project, but had to make some changes; and couldn't make heads or tails of it. Shortly thereafter I had occasion to look at some Tcl/Tk I'd written at about the same time...and it made perfect sense to me.
Had I used Perl on a daily basis, rather than occasionally, I might have stuck with it. Instead I switched to Tcl/Tk, and never regretted it.
In all seriousness mod_php killed Perl, or at least struck the fatal blow. In the late 90s I wanted to make dynamic web content, just simple CRUD stuff. The most reliable way to do this was Perl. As long as your hash bang and permissions were correct you could drop a script in a cgi-bin directory and it would work. It didn't matter if the server was Solaris, Linux, or some other Unix. Most hosts that supported Perl also at least had the CGI module installed as well.
It was worth fighting with Perl's syntax because it was the best option for web programming (for random amateurs like myself). Web hosts often didn't have C compilers available so C wasn't an option. TCL was workable but not as prevalent as Perl on web hosts. Same with PHP3. Keep in mind this was an era where you were deploying on machines you didn't on which you didn't have admin access. Most of the time you didn't have shell access on machines you'd deploy on.
As Linux adoption on servers exploded so did the deployment of PHP. It was easy to deploy PHP web apps since they could be readily dropped in your htdocs or public_html directory and be handled by the server. Enabling other CGI outside cgi-bin directories was uncommon.
So by 2000 or so there was no reason to learn Perl to do web stuff easily. You could do it in PHP which was already a templating language. The younger version of me that wanted to do web CRUD stuff bought a PHP book instead of a Perl book. With Python 2's release at that same time if you wanted to do portable non-web stuff you had a much nicer language than Perl available as well.
Shhhh don't mention Perl. The fact that Perl is still installed by default on most Linux distros is the only ray of light in the horrible devops landscape. The fact that I can write a script in Perl and not have to deal with BASH's horrible syntax is a small joy in that world. If you mention Perl too much, the people who ruin everything might set their sights on it.
Perl is powerful, expressive, and cryptic. Its popularity faded during a time when the popular trend of programming languages was towards simplicity and legibility. C++ gave way to Java and C#.
Also, Perl's strength was text processing in a world where data was moving out of simple columnar text formats and into databases, xml, json, and other formats better represented by object models than lines of text.
Personally, back when Perl 6 was harmless vaporware, I never found a place for Perl 5.
For moderately advanced text processing with regular expressions, supposedly its strong point, it was far less elegant and concise than AWK at the low end and far less readable and less batteries-included than Python for more complex tasks involving some integration.
For dynamic web pages, another of the main uses of Perl, PHP was purposefully designed and (while not really good) practical and user-friendly, with plenty of other obviously more robust and serious options (Ruby, Java, later Python, etc.) for more enterprise projects.
It sounds like Perl just wasn't your style and that's okay.
But, Perl was immensely popular, particularly in the 1990s in its 4.x/5.x days. We used it because it was precisely more elegant, ergonomic and performant than awk :-)
Later on, Python gained more traction because it was more batteries-included, and PHP evolved from being a toy named "Personal Home Page".
Perl was immensely popular, but it isn't necessarily enough to qualify for the personal "bubble" of languages one learns.
It was a good choice of proven, general purpose interpreted scripting language for you in a time when Perl competed with AWK and shell scripts, but in the 1990s I used mainly C and C++ before adopting Java quite early and almost exclusively; when I later decided to learn some proven, general purpose interpreted scripting language Python was my obvious choice: more advanced than Perl 5 and more popular than Ruby.
Even before the Perl 6 insanity dropped, there was a serious underlying problem in the Perl ecosystem: CPAN. There was this module (I don't remember its name, or author) that was pretty important: you'd end up using it if you were serious about Perl.
One day, around 2000 or so, the author/maintainer, a well-known guy in the Perl community, updated the package with an incompatible API. If you used that package, you had to update your code. There was no backward compatibility, nothing. To make things worse, the README stated that it would AGAIN change API in the future, but he didn't know yet what the change would be.
I considered this disastrous maintainer behavior, as I'm sure anyone reasonable would. It was clear I had to stop using this package, and anything else this guy could get his claws on. But there really wasn't a massive outcry that I could see, nobody calling him out for this crap.
That's when I knew I had to stop writing code in Perl. I tried Ruby but found it unstable at that time. Next project I used Python, and never looked back.
After twenty years of Perl, I switched to Python because I was encountering too many useful frameworks and systems that had no corresponding Perl packages. The last straw was when I wanted to use Mongo and found that the Perl package was unsupported.
What is dead may never die. Perl will live on in the few mostly weird places doing things other languages can only dream of. And that’s fine. Perl doesn’t need to win the race or update itself. It is good enough as it is. It’s the magic wand in the world full of electronics. Sure you can light the room with an electric PHP/Python lightbulb script. But Perl can summon a levitating glowing orb out of thin air with a single line of code.
I have great love for Perl, but I'm not super eager to go back to using it.
I used it in probably one of the more cursed contexts I've ever heard of. Understand[0] is a static analyzer for many languages, and one of its killer features is that it is programmable with a Perl API. I used this feature at a defense consulting job to help target audits of huge, multi-million LOC codebases.
Perl's expressivity was very useful here. I cut my teeth on functional programming concepts to write some very nice traversals. The runtime environment of the host program was a nightmare to deal with though.
I learned Perl back in the day. It was fun and powerful.
But I think the package management and culture killed it for me. People took pride is writing obnoxiously messy code. Package dependency hell. Gung ho borderline toxic RTFM culture.
This is evolution. Not death. It found what are its strengths that would make it relevant today and it made the leap of faith. That is remarkable.
No one need to switch to Perls 6 and Perl 5 can evolve incorporating incrementally stuff from Perl 6. Not every core team has the time, the $$$ or the devs to put forward
long term plans of compatibility.
People always expect "someone" to do it.
What Perl 5 people could do, is improve its code base, clean it up and use sane software engineering practices to make code boring, modern and much more friendly for contributions.
I think what killed Perl is that no one wants to invest into it. And not because of Perl 6.
It is a great language for quick and dirty scripts, one liners... But no one wants to start a big project in Perl, and I think for good reasons. With only the "quick and dirty" use case remaining, people didn't want to invest into a language for that, it is throwaway, that's the point. So it was left to die slowly.
I don't think that Perl 6 took away the Perl community, I don't think the people on Perl 5 and the ones on Perl 6 were of same kind, the former just wanted to continue using their "Swiss Army Chainsaw", while the latter wanted to design an innovative language. It has created some confusion, but I believe it is minor.
If I want to point at one thing that killed Perl, I would go with PHP. Websites were a common use case for bigger Perl projects. Now that PHP does it better, what's the point of Perl for that application?
Perl 4 was a great upgrade to bash as a scripting language.
Perl 5 added a bunch of complexity to remake Perl into a programming language.
It failed.
Perl 4 was a great scripting language whereas Perl 5 was a terrible programing language.
Perl 5 lost to the better (dynamic) programming languages and bash reclaimed the scripting title as Perl 4 was dead.
Interesting take! I wasn't around for perl 4. I didn't like perl 5, but I was quite interested in 6 at the start. For a moment it looked like Larry Wall had really reflected on the problems of perl 5, and was going to make a new language that was at once cleaner and more systematic, even though it had more features. Then he kept adding more shiny things and I lost interest.
As someone that was already working during the dotcom wave, Perl is a tool I would still reach for, given the problem I might trying to sort out, if on an UNIX like platform.
> Binary package managers that chase down dependencies on their own weren’t a thing until the early 2000s, I think?
UNIX package managers started to be made available during the 1990's.
I definitely had Debian installs pulling binary package dependencies automagically via apt-get in 1999, and I think similar with RedHat a year or so before that.
Debian had binary packages with dependencies via dpkg from maybe 1994. Automatic recursive downloads, with apt (apt-get) were much later, around 1998. Rpm was launched in 1997.
It's hard to remember really, but automatic downloads would have been considered quite a misfeature by lots of user sites, in an era of intermittent, metered internet connections.
Didn't dselect in Debian deal with transitive dependencies (albeit through a tui rather than a cli) a couple of years before deity/apt came along?
As I recall, rpm could list dependencies but not automatically fetch them. Full apt-style recursive downloads weren't a thing until yum from Yellowdog (a PowerMac-specific clone of RedHat) and urpmi from Mandrake, both of which arrived in late 1999 or early 2000-ish.
RedHat eventually started using yum as well, but not until around 2002.
Certainly, in the late 90s, apt was king. Debian was struggling badly with their internal processes at the time, though, so they didn't benefit as much as they otherwise might have.
I think you're right about rpm and yum, actually, my memory failed me. (I was always a Debian user, so didn't have as much direct RedHat experience). I remember yum being really slow when it first arrived too.
I don't remember dselect _downloading_ dependencies, but it may have been capable of resolving the full graph - AFAIK .deb always included dependencies
From a recruiter’s perspective, I remember recruiting full stack Perl people for a San Jose based tech company in 2010. I was able to secure one really good Perl guy who had just been laid off from Yahoo, but there just wasn’t anyone else who was relatively easy to find with the experience this company wanted. I was charging by the hour, and I distinctly remember suggesting that the company consider hiring non-Perl people and letting them learn on the job as I wasn’t going to be able to find what they wanted. They kept looking for Perl people and I kept charging them. I wasn’t shocked when an executive at the company eventually asked why the recruiting bill was so high given the lack of results.
I interviewed for Yahoo Mail in '05 - multiple rounds and they ghosted me. IIRC, it was all going to be perl stuff.. I'd done some out of necessity a few years earlier, and hated it.
In hindsight, glad they didn't respond - got a much nicer EDA startup job a month later working with Tcl/Tk (which I had already used for ~10 years at the time).
I had to use Perl in a recent project to perform health checks on a container. The container authors decided not to provide /dev/tcp or curl, and I didn't want to add the extra headache of maintaining an upstream fork with curl, but they did include Perl. So I (claude) wrote a one liner script that imported the networking lib and performed the check instead.
(Side note, I know "slim" containers are all the rage these days but please please please please just put curl in your unix containers or provide a script that lets me check the container health. I don't want to spend more than 5 minutes setting this up or I'll just look for something else)
I use shell, vim, sed all the time (awk less but i have used it). I've never used perl. I don't even know if i've ever even encountered a perl program that i wanted to look inside.
I think its just one of those things, they lost mindshare and people stopped making stuff in perl. Network effects made it snowball from there. How often do you see code examples written in perl? Almost never. I see people write blogs with code snippets in python, c, rust or even shell all the time. Never perl.
Momentum matters and perl lost it. I think of perl the same way i think of cobol or fortran.
Around 2010 I ditched Perl for PHP because I had been using PHP for web and could write the same systems scripts in PHP as I used to write in Perl. Sticking with one go-to language is easier on the brain.
I love Perl. I think, though, that the crazy mix of sigils and braces/brackets to work with complex data structures was one of the main reasons.
Especially for the type of users were Perl had gained some ground in the past...data science, DNA related stuff, etc. Non programmers.
If you look at just about any other language and how you would pull data in and out of json yaml, manipulate individual elements, etc... the Perl is just hard to decipher if you don't have immediate recall of all the crazy syntax for dereferencing things.
Perl is what killed Perl. I have never had as many "tear my hair out at 4AM" debugging sessions as I have had with Perl, because I missed some weird character somewhere.
Disclaimer. Perl was my first real language. I have several contributions to Perl, including a complete rewrite of Carp.pm. For a number of years I was also on the Perl 5 Grant Committee.
I completely discount the basic syntax as an issue. Sure, it is an easy thing to complain about. But I've personally seen a number of people with no background master the basic syntax very quickly. In fact I was able to teach myself from the Camel book with absolutely zero background in the various languages that are supposed to help you. And during the dot com era, most of the people writing CGI scripts in Perl, similarly lacked a programming background.
The first issue was the fact that a lot of bad Perl got written. It was remarkably easy to pick up a bit of Perl, then write a bunch of code. This code was generally bad, useful, and full of security holes. (Thanks, Matt Wright.) Most people's exposure to Perl was to this kind of code, and it left a permanent bad impression.
The TIMTOWTDI (There Is More Than One Way To Do It) philosophy fed into a widespread cowboy philosophy. People took pride in their mastery of Perl, and demonstrated it by using obscure features. Like, say, C++, many subsets of Perl make for good languages. But if you try to use all of the features at once, the combination doesn't play well together.
That said, there was a significant group of people who grew and improved together. They learned best practices, wrote good CPAN modules, and elevated their game. But this group fell into a different trap. They learned the immense productivity of small teams. But organizations filled with small teams of senior programmers, don't have a way to mentor junior programmers. This cut off the pipeline of future developers. Losing that pipeline is an organizational threat. How do you find maintenance programmers down the line? Many organizations that had a lot of Perl, then put a lot of work into trying to move away from Perl. A significant number of Perl programmers saw the writing on the wall, and took the opportunity to move away from Perl themselves. This resulted in very few new companies being built around Perl.
(Incidentally the same "no pathway for junior programmers" problem is becoming a big issue for programming in general because of LLMs.)
For the next problem, we have to go to perl5-porters. The group that maintained the core of the language.
Let's start with a key individual. Tom Christensen. Brilliant, productive, and a technical genius. But also confrontational, unstable, and a toxic influence that shut down Perl development. This was a major reason why the Perl 5.6.1 release took over a year to get important bug fixes out. Tom also drove a number of people out of the Perl core.
Then there was an underlying tension between two major groups. The first were people who wanted to take Perl, and run with it. Adding all sorts of new and interesting features. The opposing group was those who cared about production, and wanted to be reaaally careful about breaking anything.
This lead in 2000 to a famous cup throwing incident by Jon Orwant. Larry's solution was to behind the scenes put a muzzle on Tom, and start the Perl 6 effort. That way people who wanted new features could go off and play in the new sandbox, while those who wanted to support existing Perl could stay in Perl 5.
Over time a lot of the good ideas in the new sandbox got ported back to Perl. See, for example, Moose. The spread of these technologies meant that there was a lot of progress within the Perl ecosystem. Unfortunately this came as the Perl ecosystem itself was shrinking. The language itself improved a lot. But the programming world in general didn't notice, and didn't care.
I should have also mentioned that I was tilly on Perlmonks. For a long time I was the top rated poster, on the dominant question and answer site for Perl questions.
Life is alright I suppose. There’s been a lot of cancer in our families, which is rough. There’s been some wonderful responses to treatment though. My job since late 2022 I mostly really like. My fiancee and I moved from Texas back to Illinois in June. We got engaged in late August.
I’m sorry to hear how life’s treating you. I wish you well.
If you want to connect on some social media platform, I’m on FB, Mastodon, and Bluesky. Or I do check Perlmonks still once in a while, and Slashdot.
I may blog about this next year, again[^1], as I'm working on a project that sort of covers it - not in a way that will answer the question but more observational.
Anyway, I feel Perl's popularity was hugely exaggerated in the mid to late 90s and early 00s. The alternatives were either not there in terms of language and toolchain features, ease of use, "whipuptitude" or whatever, or library support (CPAN was a killer app), or they were too old school or enterprisey. Sysadmins were using it everywhere so it got into all sorts of systems that other languages couldn't without much more faff.
Its back compatibility meant it stayed in those places for a long time. It's still in a lot of those places.
The fall in popularity the last decade or two was more of a regression to the mean, or perhaps below the mean. Many other languages have come along, which have contributed even more to the fall in share.
Yes, yes, Raku (né Perl 6) but I'd argue that also contributed to a lot of really good stuff on CPAN. The Perl 5 core did get neglected for a number of years, as @autarch says, which may have been a factor.
What put perl out to pasture for me was lack of static types, nor any capability of adopting them. We were told to wait for Perl 6 for that, and well, we saw how that went. I'm told that disabling indirect object syntax gives Perl a fighting chance at static analysis, but that in the end it's still the case that only Perl can parse Perl.
Did some major projects for my employer using Perl (coupled with Java of all things) in the 90s. Then I learnt Ruby and put aside childish things (jk). I then dropped Ruby for Elixir and Python for the sort of projects that I would have used Perl for, back in the day. As a semi-retired sort, I now keep my Elixir and Python skills up-to-date and can't remember the last time I even tried to read any Perl. I know it's still there, doing work, but then so is COBOL.
What I miss from then are the O'Reilly books about Perl. Peak O'Reilly. Every one a joy to read and packed full of goodness. Without being 1,000 pages long. Oh, and CPAN.
Perl 6 was only ever a distraction - I was already out of love with Perl by then and Ruby (and obviously Rails) came along at the right time for the next project.
I was a happy perl user for a long time, probably until sometime in the early 2010s. I am a sysadmin and perl was a great tool for what I needed to do.
Jim Weirich was a heavy perl user for a long time, and we were both involved in the Cincinnati perl mongers group. He found ruby and fell in love. He thought Ruby would be a good fit for me and we had a long conversation about why he preferred it to perl. It took me a few years, but I eventually took his advice. As usual, Jim was right, and I haven't written any perl since then.
Something I haven't seen mentioned is that python is very commonly taught at universities. I learned it in the 2010s at my school, whereas I never got exposed to Perl. The languages people learn in school definitely stick with you and I wonder if that plays a non-zero factor in this.
Been using Perl since the beginning… essentially every time I needed to write a shell script more than 10 lines long I used Perl … eventually was also using it for web back end stuff too … kind of like duct tape. I still use it today if I need to write more than 10 lines of a bash script.
I have been using Perl for almost 30 years now, privately and professionally. People here tend to say, Perl 6 or Python killed it, but that's not what I experienced in those 30 years. Not that simple.
It was a combination of things, the Perl 6 announcement was one of the smaller parts actually.
- TIMTOWDI lost against "batteries included", and it lost big: It's not so much that the simpleness of the Python language won over Perl, the real and absolutely major problem at that time was the success of CPAN, which "killed" Perl 5. Perl 5 would have needed ONE object system, ONE base exception class, ONE way to do function signatures. Instead at the time, it came bundled with a bunch of Perl 4 utilities which nobody dared unbundling, CGI and a handful math functions. Being able to pick is nice, but everybody else did pick, too, and so if you used any CPAN dependencies, you soon had 3 incompatible object systems, 4 type systems, 5 exception systems co-existing within your project. A problem Perl has to this day and the reason why my team tends to re-implement stuff instead of pulling in dependencies. Python's "batteries included" approach easily won out, because stuff worked with each other and you didn't burn then scarce RAM on having different implementations of the same thing.
- Perl started to lose at the low-cost hosters against PHP already pretty early. It was easier during a certain time period to have a halfway performant PHP installation than a performant Perl installation. Hosters usually only offered CGI for Perl, not mod_perl, while PHP usually was offered as FastCGI module or mod_php which supposedly was easier to install. No low cost hoster wanted to mess with mod_perl, because it always was a hassle to setup.
- Speaking of mod_perl, things in the web dev sector still stayed pretty stable as long as Apache 1 ruled. People had to use mod_perl, but then you had a pretty performant solution. Then Apache 2 came around but mod_perl 2 wasn't ready for a long time (honestly I don't know whether it ever became ready). The Perl community at that time appeared entirely unprepared for that. While Python users were accustomed to run standalone Python servers behind proxies, Perl always was relying mostly on mod_perl. But threading in Perl stagnated and ran against a wall, and Apache 2 preferred multi process multi threading modes versus the simpler prefork multiprocess model that Apache 1 and mod_perl 1 ran on. This was the time were you could basically feel the creaking and everything breaking apart: suddenly there was no clear path forward, with mod_perl2's stability issues and the general threading stability issues of Perl 5.
It took years for the community to recover from that and focus on things like the Python-inspired PSGI/Plack as a way forward.
So, how does Perl 6 fit into this? Yes, in the early 2000s we did think, it would be just around the corner and be a clear upgrade path and solve everything wrong with Perl 5. Nice fantasy at the time. But at the same time, people were busy with far more pressing immediate problems, like how to migrate away from mod_perl1. When Python's WSGI and soon after that, Ruby on Rails came, they pressed directly into the vacuum left open by the mod_perl 2/Apache 2 disaster and this is actually what sealed the deal, IMHO.
> No low cost hoster wanted to mess with mod_perl, because it always was a hassle to setup.
I am not aware of any way (back then) to run mod_perl, which was powerful enough to facilitate developing Apache modules directly in Perl, safely in the shared hosting environments that most people used in the 2000s. If you wanted Perl, your options were either classic CGI, with the overhead of script recompilation and a new perl process spawned for each individual HTTP request (even if initially handled by the same Apache process), or paying up for a dedicated server/VPS just so you could run mod_perl.
How the Perl community thought this was an acceptable state of affairs, especially given how big of a driver webdev had been of Perl uptake during the .com bubble, when Perl was affectionately called the "duct tape of the web," and how they just sat by and let PHP eat their lunch, I'll never understand. But the attitude of the Perl community then was this mix of old-school UNIX/USENET "RTFM" culture and a dubious sense of cockiness (instilled through catechisms and catchphrases, like JAPH), so they weren't going to bend-over backwards to attract and accommodate new blood, expecting Muhammad to come to the mountain.
Back in 1994, Perl was an amazing thing to me (as someone who was accustomed to mainframe scripting languages up to that point), and it helped make me very productive. But it sometimes would seem like the epitome of "Write once, read never". Tim Bray even remarked on its abstruseness back in 2003:
My personal reason was observing the huge amount of investments into Javascript and its infrastructure (by Google and others). After Node.js was released it was a rational bet to make that Javascript would dominate, both server and client side. As someone who often does both front end and back end, it felt good to move to Javascript. It's got to be said that keeping a "common" directory around with shared code for both front- and backend is still a PITA, but still better than most other alternatives.
It's definitely more powerful and has less foot guns than bash, the problem is the stigma is worse than bash. You will face more scrutiny and possible derision from your colleagues for using Perl than bash. It's not just questioning your taste or style either, it's because of the fear they might have to one day maintain or try to understand your Perl.
I speak from some experience. Because I'm a 90s UNIX nerd, I quickly hacked up a a bunch of stuff in Perl maybe 6 years ago to solve some text processing tasks for a compliance audit. It worked well and got the job done within the time constraints. I actually got some kudos for getting our team out of a jam and doing grungy work people weren't keen to do. My teammates though, they lost no opportunity to dunk on the fact that it was done in Perl, and questioned my decision at every opportunity. I ended up rewriting the whole thing in Python for our next audit.
The opinion of coworkers is not a factor - but I have a friend who says that he has to relearn Perl every time he needs to use it. Do you have to use it every day to maintain fluency?
It doesn't take too long to get back into the swing of things. After a while, if you learn enough programming languages, they all tend to meld together in your brain, and the cost of switching isn't too disruptive. You know what you want to do, it's just the details that temporarily get in your way.
Yeah, as someone who occasionally had to hack on perl scripts - and I mean, maybe add/modify a hundred lines to add a new feature, then nothing for a few months, I found this too. Stop doing it for a while, and I had to relearn it all over.
I'd probably have an easier time getting back into REXX that I last used in 1992 or something..
It’s strong as a better shell. Perl is even getting an increasingly good and complete default object model in the core language. One of the big complaints was always that the TIMTOWTDI included object libraries, of which there are many. Most of the popular ones are working on becoming wrappers around the new core one, and you can write new code directly with what’s in core.
There are a few places where you might dig and find a perl script under the covers. Some that aren't replaceable with bash (and sed and awk).
I suspect that my "diff these two java deployments and create a file by file update script to run on the remote machine" in perl is still running for doing incremental deployments... and if someone uncovers it its still something reasonable to understand.
However, if I was tasked with that today... dunno. I'm not sure I'd reach for the same tools as I did then.
> In devops is turtle all way down but at bottom is perl script.
In the early 2000s Perl was godsend. A dynamic language that helped solve a lot of problems very quickly. But as soon as projects got larger and/or others joined your codebase you realized it does not scale. For me that was the moment when I slowly migrated to Python. So for me Perl‘s syntax (&@!#%), the easter eggs in the language, and the thousands of ways to be able to write things, killed it. It was just not maintainable.
I heard a fascinating theory a few years ago on the decline of Perl:
In the early aughts, Google SRE recruiting had such a strong, selective focus on A-player sysadmins with Perl expertise that it drained the market of top talent. Within google these people began to adopt, and eventually create and evangelize newer, Googlier programming languages.
In other words, Perl expertise was the skills filter, and Perl itself a technological ancestor of certain modern languages like Go.
I worked at Booking.com for a year or so around 10 years or so, and most of their stack was in Perl. Folks there had mixed feelings about it, I'm not sure what things are like now, but I assume they're working to replace it.
Ah yes, that's it. I had to hack on Bugzilla to customize it for our start-up.. Back in the day BEFORE they added a lot of end-user customization... UGH..
I think Perl was very tied to Unix idioms. I love the language to this day and found it incredibly expressive for developing small order of magnitude programs.
Python was more opinionated, and better able to integrate with external libraries. A lot of the heavy lift in python is really invoking external code from elsewhere. You can solve “real” problems with readable code without the learning curve of C or Java.
Perl became popular because there was not really an alternative on par with its capabilities and because it was bundled with every Linux distro.
But then Python came along and picked up momentum and because of that, people realized Perl's syntax is actually not very intuitive to read and understand compared to Python.
PHP and Python did. PHP so much better for web development, and especially faster due to being linked with the web server instead of in cgi-bin, and python by being a much cleaner and easier to use scripting language for batch jobs etc.
I still have nightmares about the time we were trying to write the server part of a distributed filesystem (the precursor to Lustre) in Perl.
the ever infusion of new blood is what made Javascript & Python to be in top 3 languages today. Even though things like Ruby were easier for some. Ruby not being easily installed on windows back then stopped new blood as well.
for language designers / framework designers -- make your stuff easy for beginners then it easily grows.
I sometimes wonder how different things might have been if Perl had been the dominant scripting language at the time that ChatGPT, Codex, Claude Code and other tools like that became available.
Would Python have been able to compete, in a world where Perl could be readily comprehended by LLMs?
So, maybe what killed Perl was lack of VS Code forks and lack of being agentic.
So then we'd have 100x as much "vibe coding" as now? <shudders>
Even if I disagree with our AI code assistant's usefulness - it often just suggests code based on "someone else in a different file used this statement after that last API call" that is totally irrelevant to my current needs - I can usually assess AI-generated code (C++ / python) relatively quickly and determine if it's what I want or not. It generally nails the "you just created this variable and now want to print it to the log" part pretty well.
Debugging AI-generated perl?? It would be like trying to follow "obfuscated C contest" entries all day, every day. No thanks!
The flip side to this is that perl often favored brevity over simplicity. It turns out that this is also a really useful attribute when working with LLMs. I'm not sure how confident I am here, but it really wouldn't surprise me if LLMs could both generate and explain remarkably complex perl code!
I'll give you my two cents - I took a job in Perl in 2017 and set about learning it and found its community to be the most snobbish and unfriendly of any programming subcommunity I had ever encountered.
The language had many strange quirks and every question I posted about its particularities was greeted with responses along the lines of "Are you even trying? How do you not get it? Did you even read the docs?"
Well, yes, I did, and I still didn't understand, because I found them unclear.
I left the job and dropped the language and moved on to greener pastures without much regret. And it seemed like many, many people I spoke to had similar experiences with it.
The last time I dealt with the Perl community, I posted a question asking for an update on some announced changes. In a community of adults, it was a straightforward question with a straightforward answer, but that's not what you get with Perl.
What killed it was that a lot of its development talent effectively went off and worked on a completely different programming language that eventually got released a Raku.
When the team departed, Perl lost its development velocity and Python wasn't that far behind.
For me the three sigils of Perl $, @, % are the “holy trinity” of scalars, lists, and dicts that are foundational to dynamic languages like Python and Javascript and are used all the time in static languages like Java or Rust when your data is dynamic.
It's the only programming language other than C which actually needs a tutorial on how to use arrays of arrays. It's a part of the standard Perl doc, appropriately named "perllol": https://perldoc.perl.org/perllol
Most popular languages (Python, JS, Java...) as well as classics like LISP manage references transparently - the distinction between "array" and "reference to an array" is abstracted out.
In Perl, it isn't. It's a language with some archaic elements of manual memory management and parameter passing quirks. It's very clear that Larry Wall was not guided by programming language theory or math-inspired abstractions, but "whatever shit would be easiest to implement" (from https://perldoc.perl.org/perlsub#SYNOPSIS):
> ... any arguments passed in show up in the array @_. The array @_ is a local array, but its elements are aliases for the actual scalar parameters. In particular, if an element $_[0] is updated, the corresponding argument is updated
Theorists described call-by-value, call-by-reference, etc. But our man Larry came up with pass-via-a-local-array-but-its-elements-are-aliases-for-the-actual-scalar-parameters. I can see how one can quickly hack this together. But maybe it's time to retire this.
Yeah, it was always a headache to put together complex data structures in Perl. It's kind of like bash in that way. Every time you need something like "a hash table that contains lists" it quickly turns into a quagmire. In Python you just... do it.
Let's not forget that Perl 6 was announced because Perl 5 usage was already stagnating. Perl 6 was supposed to fix that problem. But it ended up making it worse.
It would literally just be Python (and probably some php and maybe even ruby) plus "Bash is good enough and more ubiquitous for the things you don't need all of Python for," no?
I spent 10 years in perl and created a lot in it - it taught me a lot about code as a culture,importance of tests, TIMTOWTDI, etc. I think I owe a lot to it.
I found myself defending it more and more online against the folks who were nay sayers - those who complained about its syntax and it's quirks - but that wasn't a problem for unixers who used sed/awk/vim and all the other arcane tools. Perl wawa means to and end and it was the best tool to reach for (the glorious Swiss army knife).
I guess there was an infection period - the brain drain to python and Ruby meant it was harder to find decent quality libs on CPAN anymore as folks would only do things in python. And Yea, while CPAN is still rich, it's not the first hit on Google anymore.
Today, the map-sort-map Schwarzian transform is still the easiest to do in perl than any other language and it helps me whip up the throwaway scripts quick. Wouldn't change the language - I really love it!
Perl isn't dead. Perl is the only stable actively developed language. Code written in 2003 runs today and perl code written today runs on a perl interpreter from 2003. Because of this perl is by far the best language to do system administration. It is both ubiquitous and stable. Other scripting languages like python constantly have breaking changes and frankly, you have to have a special separate install for every python script you try to run. With perl the system perl is always enough. No containers needed.
You can call it dead. That's fine. Keep it unpopular. Popularity kills. Popularity leads to a language becoming dozens of different incompatible things. Perl is quietly amazing. I write once and run anywhere, anytime. Other languages can only dream of this.
As I have said before[1], I think the biggest thing slowed Perl adoption was the changing background of new developers. New folks just didn't have a background in shell, C, awk, and sed. This fact took Perl syntax from being amazingly intuitive and easy to adopt and turned it into obscure nonsense. As a newb what the heck are you going to think about constructs like the file test operators[2]?
Um, does this guy realize that the dotcom boom was 25 years ago? The software field has grown exponentially bigger since then. Perl being "as popular as it was during the dotcom boom" (even if true) basically means that it's dead.
[edit: also, even his own graph of "releasers" shows that if current trends continue, there will be essentially 0 "releasers" in 10 years]
Perl was the internet in 1990s. People (me) who were doing unix systems work (C, shell, Perl and some DBs and FTPs) could now quickly throw a CGI script behind an Apache HTTP server, which tended to be up and running in many unixes :80 port back then (Digi, HP, Sun, etc). Suddenly I had a working app that would generate reports directly to people's browsers or full-blown apps on the internet! But Perl CGI did not scale at all (spawn 1 short-lived process per request will choke a unix fast), and even after mod_perl [1], that got quickly superseded by PHP, which was really built for the web (of the 1990s). Web frameworks and fastcgi arrived too late to Perl, so internet Perl was practically dead at the turn of the century.
The enterprise, who either did not have any webapps or had tried Perl CGI first and suffered it dearly, got pinged by their sales reps that Java and .NET (depending if you were a IBM, Sun or MS shop) were the way to go, and there they went with their patterns and anti-patterns for "scalable" million-dollar web stacks. That kicked-off the age of the famed application servers that resist up until today (Websphere, Weblogic, etc).
So Perl went back to being a glue language for stitching up data, C/C++ and shell, and that's how the 2000s went by. But by then, Ruby and Python had more sane communities and Ruby was exciting and Python was simpler - Perl folks were just too peculiar, funny and nerdy to be taken seriously by a slick new generation that coded fast and had startup aspirations of the "only $1B is cool" types. Also the Perl6 delusion was too distracting to make anyone event care about giving Perl5 some good love (the real perl keeping servers running worldwide), so by the 2010s Perl was shooting down to collective ostracism, even though it still runs extremely well, fast and reliably in production. By the 2020s the release cycles were improved after Perl6 became a truly separate project (Raku, renamed in 2019), the core has gone through a relative cleanup and finally got a few popular features in demand [3]. The stack and ecosystem is holding up fine, although CPAN probably needs some good tidying up.
The main issue with Perl at this point is that it has not been a target for any new stuff that comes out: any cool module, library, database, etc that is launched does not put out a Perl api or a simple example of any kind, so it's up to the Perl community to release and maintain apis and integrations to the popular stacks on its own, which is a losing game and ends up being the nail-in-the-coffin. By the way, nothing (OSS) that comes out today is even written in Perl. That reduces even further the appeal of learning Perl.
Strangely enough, lately Perl has seen a sudden rise in the TIOBE index [4] back into a quite respectable 9th position. TIOBE ranks search queries for X language and is not much of a indicator, being quite noisy and unreliable. My guess is that those queries are issued by AI agents/chats desperately scraping information so that it can answer questions and help humans code in a language that is not well-represented in the training datasets.
I have a problem. I know, I'll post a dismissive, overly reductive platitude and farm points on HN.
Perl 5 is a great language far ahead of it's time, it's extremely functional, and it still underpins many large and important systems to this day. No, it's not perfect, but it's the first time programming where I ever felt like I was having fun writing the code as opposed to achieving a means to an end.
I admittedly have no experience with Perl 7 and didn't like Raku. Sometimes worse is better.
Perl 5 was abandoned for a reason by people who developed it. Something I you never see happen in other languages. Planned successors did not catch up.
Perl does not scale. Very few people want to maintain Perl code. The write only reputation is not without merit.
It is without merit. There are more than a handful of modern internet companies running on Perl. Amazon runs a LOT of Perl for CDO. Who has scaled more than Amazon?
This is a very ignorant take that selectively chooses to look at the fact that you can write Perl poorly, because the language does not stop you from doing so, and ignores the fact that you can also write it in a maintainable fashion.
People stopped working on Perl for a variety of reasons. The commitment to backwards compatibility to a fault. The reputation leading to lower adoption. And so on. None of these are structural problems with the language itself, they are more community/bad luck issues.
The backwards incompatibility of Perl 6 absolutely killed Perl.
There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use because they still have momentum and lots of legacy things built in them. So being ugly or old isn’t enough of a factor for people to abandon something in droves.
Once you need to rewrite everything, there’s no reason to stay with something you know since you need to fully retool anyway.
As a Perl programmer since v5 was released, the confusion around 6 completely destroyed almost everyone’s enthusiasm, and immediately caused all new projects to avoid Perl. It seemed like 5 had reached the end of the line, and 6 was nowhere to be found. Nobody wants to gamble so many hours of their lives, and the future of their business, on such an uncertain environment.
If Perl 6 had any visible movement within the first few years, it might have survived, but it was a good decade before they even admitted Perl 6 might take longer than expected, and then more time after that before they admitted it should have been a new language. 6 was interesting for language geeks, and they probably did some cool things, but you can’t run a large popular project like it’s a small research project. That completely destroyed all momentum in the community. Perl 5 development only resumed far too late, after the writing was already on the wall.
Both Bill Gates and Linus understand backwards compatibility as a sacrosanct principle. Python only just barely survived the jump from 2 to 3. JavaScript can only survive this because there’s no other option in a browser.
> Python only just barely survived the jump from 2 to 3.
I really don't think this is true at all.
Python 2 to 3 took a really long time, it was a real struggle, lots of people stayed on 2 for a really long time.
But I really don't think Python was close to dying the same way Perl has/is. There was no risk of Python not "surviving" in my opinion.
There was always a clear way forward and people were actually moving. The mass migration of millions or billions of lines of code from 2 to 3 actually happened and has many high profile million+ line migrations, like Yelp or Dropbox.
There was never anything similar for Perl 5 to 6, totally different situation.
> I really don't think Python was close to dying
It absolutely was. What saved it was:
1. The data science / AI crowd that was gathering momentum any many only used Python 3.
2. No popular alternative. Perl got python as an alternative.
Python was also a good, simple language and had a good healthy culture. But it's nothing sort of a miracle that it survived that biblical software calamity.
You forgot perhaps the most important one:
3. six
`six` was instrumental in repairing the Python schism by giving people a way to incrementally move their 2.7 code to Python 3, and write code that was compatible in both. The six project didn't exist at first and the path to Python 3 was too painful without it. Six solved all that by smoothing over built-in libraries with different casing between versions, incompatible core libraries, the addition of unicode strings, print changing to a function, etc, etc. Perl 5 to Perl 6 (aka Raku) never got that.
Six was one component but not the only one. Python 2.7 also backported a number of early Python 3 features, Python 2 features were reintroduced in basically every P3 version until at least 3.5 (although after 3.3 they were pretty minor), and a lot of extensive migration guides were written (my main bible was eevee's).
In my experience, six was a relatively minor part, and you could get by with your own little compat file for just the stuff you needed, even on relatively big projects. I even found it beneficial to do so because instead of just slapping six.moves everywhere you'd have to re-evaluate some of the old decisions (e.g. at $dayjob at the time we were using all of urllib, urllib2, and requests for HTTP calls, not using six provided strong motivation to just move everything to requests). This also made for a lot less churn when removing Python 2 compatibility.
> Python 2 features were reintroduced in basically every P3 version until at least 3.5
If they had just done this from the beginning there wouldn't even have been such upgrade drama in the first place... like, as an obvious example, removing u'' syntax for unicode strings immediately at 3.0 was just idiotic: if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all (a la Ruby 2's Unicode reboot, which concerned a lot of people but was a nothing-burger next to the insanity of Python 3).
Sure but importantly they did realise they had erred and course-corrected.
> if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all
Having been there and done that, nah, the text model changes alone required significant work to square up in most packages. And there were plenty of other semantics changes.
But you could have made those changes incrementally in a way that more cleanly worked across both Python 2 (which already had this split: the default type was just wrong; all of my code, for instance, worked great!... it was just super awkward, as it had tons of u's thrown all over the place). Where they ended up with the language (after, like, 3.7) was much more incremental from Python 2 than the early path to how they got there. To be explicit: it isn't about having to put in upgrade effort, it is about upgrade discontinuity.
As a user, you may not appreciate six, but popular libraries like Django would've never made the jump without six.py;
I’m not talking as a user, I’m talking as a person who ported 350kLOCs of python from 2 to 3.
Django absolutely would have been ported: it was ported without six by Vinay Sajip (building on an earlier work of Martin von Löwis). In fact a limited shim layer was initially committed based on Vinay’s efforts: https://github.com/django/django/commit/5e6ded2e58597fa324c5...
The team ultimately decided to use and re-export six for the convenience of the ecosystem, not out of any sort of necessity.
It's very true, I feel like one of the most useful things python had was stuff like "from __future__ import print_function"
six did help a lot. Didn't help with some things, though, like strings vs bytes vs bytearray.
Python 2.7 was kept very much alive, with a number of small improvements from the 3.x branch backported to it.
Big players, like Django or SQLAlchemy, kept versions both for 2.x and 3.x for quite some time. This allowed for a smooth transition, when all of your dependencies finally had good versions for 3.x.
The difference between Python 2.x and Python 3.x was not dramatic. I would say it was mostly cosmetic up until 3.5 when async landed. Even with these small changes, the splitting of byte strings and character strings alone (an obvious move towards sanity) was plenty annoying for many projects.
Communities and ecosystems are fragile; sharp turns can easily break them.. Even careful maneuvering, like the Python 2 → 3 transition, put very visible strain on the community. A crazy jump that was Perl 6 was not survivable, even though Raku may be a fine language.
> the splitting of byte strings and character strings alone (an obvious move towards sanity) was plenty annoying for many projects.
Python 2 had both, it was a rename, not a split. unicode -> str, and str -> bytes. The "u" string prefix was also removed, which made migration of string-heavy code more of a pain than it needed to be, until it was added back in in 3.3
I was not affected by Py3 at all. First I completely ignored it for five years while it gestated. Then started kicking the tires when 3.4 dropped on a LTS. When 3.6 with better dicts and f-strings landed I moved over with barely a whimper, since I'd had a decade to get things upgraded to 2.7 first.
None of my projects needed to worry much about char encoding, and I'd used logging extensively starting under 2.6 or so.
Porting your own code was relatively easy. The problem was porting all your dependencies, and replacing the ones that were abandoned and didn't support 3.x.
I did wait a bit for Django and SQLAlchemy but it wasn't long, they may have been ready for 3.6. Small deps were replaced or eliminated.
They were ready long before 3.6, sqlalchemy added support for Python 3.1 in 0.6, and Django 1.5 introduced support for Python 3.2 on an experimental basis with 1.6 removing the “experimental” bit.
Long before the AI/data science breakout, we were noticing in our consulting practice (2016-2020) a sharp dropoff in Ruby at startups, and Python as the modal language (by the time I left in 2020, it would have gone Python -> Node -> Ruby).
So no, I don't think AI saved Python; it was fine before then.
2016 already puts one far into the AI explosion. The current hype cycle, with LLMs as a service at the forefront, arguably makes python less relevant than in it was in the mid 2010’s. The current crop of “AI Engineers” can use whatever languages they want for the most part. In 2016 most practitioners were leveraging a lot more of the standard scientific computing frameworks afforded by python.
Python was the lingua franca of data science by 2016, but AI and data science was clearly not the reason startups were building in Django and Flask --- the data science teams were always a morass of Jupyter notebooks and pickle blobs.
> No popular alternative
I can easily imagine a scenario where Julia could have taken the data science crowd and Node.js could have taken everyone else. People like Python, I guess.
Before JS had promises, JS code was plagued with the callback pyramid of doom. You needed an advanced masters degree in masochism to endure that. I don't think Python devs would have liked that.
I don't know. Isn't Python still viewed as a mess now? I was thinking of taking the time to learn it as the best way to write cross-platform utilities, but encountered a lot of negative sentiment about its ecosystem. And all the environment managers you seem to need for it are a turn-off.
Granted, this is coming from a relative noob who read and followed a couple of "how to set up Python properly" articles and that's about it. But I pretty much decided to spend my time on JavaScript, despite its cumbersomeness for implementing simple utilities.
It's vastly improved now. With uv, many times you can download a new utility off GitHub and run it with `uv run foo.py`, including fetching its dependencies.
Cool, thanks!
>Isn't Python still viewed as a mess now?
Imo the coding part is fine. I have no mayor complains about it. I even like indentation as syntax as long as you use tabs :)
Python is the modern day BASIC. Slow interpreted lingua franca. As long as you are ok with its speed I say go for it. Python is the only scripting language where I maintain constant lingering awareness that every single line of code adds milliseconds to run time. As bad as instantiating new variable costing single digit ms on a GHz CPU. This quickly adds up the more you are trying to achieve.
Example benchmark, Python 3.4:
In latest versions Enums got "fixed" to "only" 3-6x slower than strings! SimpleNamespace to the rescue.Its much exaggerated.
Its got a big standard library so you can do a lot by just installing Python. On a lot of *nix systems it will all be installed already. For simple use cases you do not have to have the environment manager.
I have had few problems with virtualenv in any case.
Where you are most likely to have problems is cross platform deployment. If you are going to package it as an exe for Windows users, and package it for major Linux distros, and whatever you need to do for MacOS etc. its going to be a pain. In that case there are multiple languages that might suit you better than JS.
Python is great for data science. Anything where you need to wrap a C library like BLAS, tensorflow, PyTorch, matplotlib, numpy.
It's hot garbage for writing simple cross-platform utilities because of the need for an elaborate environment setup, painful dependency management, and constant compatibility breaks.
Anecdotally, I stopped using python for several years around the transition period from 2 to 3 because a number of libraries I used at the time were in flux with 3 support (beautiful soup I _think_ was one? I could be misremembering). Ironically, I ended up just using perl for a scraping tool instead, which it's quite good at for quick and dirty scraping scripts (PCRE.) Nowadays I use ruby for that type of stuff...
You're contradicting yourself - if Python had no popular alternative, what would have new people used instead and what would existing code have migrated to?
It was close to dying, except for these two things that mean it definitely wasn't close to dying?
"Having no popular alternative" is not something that was close to not happening.
IMO javascript was a valid alternative. Easy to learn and easy to run. That's the main things needed for academic work
Python had a history of tooling/libraries that made it well ingrained into academia
Javascript didn't have the same FFI story with C/Fortran as Python. That's what allowed libraries such as numpy, scipy, pandas, etc. to flourish.
If Golang was around, it might have killed python then I think. To many, the 2->3 jump made little sense. I honestly wish they just started a new language instead.
I still to this day stumble upon code I have to use 2.7 on, thankfully things like pipx make it easy these days. but still,switching back and forth could be a pain.
But you're right, it wasn't like Perl 6. People moved to python and php mostly from perl. what were going to move to from python 2? Ruby?
Python 2.7 was EOL'd at the start of 2020, and serious effort to move from 2 to 3 didn't start until around 2018, by which time Go was a very major player.
I meant when 3.0 was released. By the time 2.7 was EOL'd 3.0 had gained enough momentum to be a viable alternative. It was easier to just migrate to 3.0.
In 2018, I don't know if Go was a major player, both it and rust were still new-ish languages. There was still a concern of being able to hire devs if you used them, where as not so much in the past 4-5 years.
> By the time 2.7 was EOL'd 3.0 had gained enough momentum to be a viable alternative. It was easier to just migrate to 3.0.
~3.8 at the time, not 3.0. 3.0 was a mess.
Major-ish. It was getting experimental module support around 2018; arguably go get was already better than Python's mess, but it wasn't great. It wasn't that widespread in industry yet - we could very rarely hire anyone with a Go background at that point.
Pretty major. I started using Go in like 2009 or 2010 and industry adoption was already pretty wide in the mid 2010s (largely replacing Java moreso than Python, IMO).
> I still to this day stumble upon code I have to use 2.7 on
There's always Tauthon (Python 2.8), lol.
Can you imagine if the PSF had been working on Python 4 in parallel, with more backwards compat shifts or even a radically modified syntax?
I think another saving grace was, when considering Python 3, one's choice was between "easy-ish migration to best in class" and "difficult rewrite into second-best". Meanwhile with Perl 5/6 it was "two moderately hard migrations into metastasized shell-script has-been language" and "difficult rewrite into best-in-class with lots of upside".
The delta between python 2 and 3 was much smaller than the delta between perl 5 and 6. Perl 6 might as well be a totally different langue which is probably why they renamed it to Raku, to stop people thinking that it was the same language.
I know companies with a big Python 2 stack that rather preferred to rewrite in typescript than migrate to Python 3
I turned down one of those companies because I didn’t want to deal with that migration in 2021
I will never forget Mercurial's postmortem on their experience with the Python 3 transition. They had very few kind words to say about the process.
https://gregoryszorc.com/blog/2020/01/13/mercurial's-journey...
Part of me even wonders if the transition had any role to play in why Mercurial gradually lost whatever foothold it had in the DVCS ecosystem.
For the crowd I ran in the lack of real branching and the need to use DirState or Queues for selective commits made Mercurial feel too much like p4, where git felt so freeing, especially with spikes etc...which would be forever in the repo with Mercurial etc...
> This ground rule meant that a mass insertion of b'' prefixes everywhere was not desirable, as that would require developers to think about whether a type was a bytes or str, a distinction they didn't have to worry about on Python 2 because we practically never used the Unicode-based string type in Mercurial.
> In addition, there were some other practical issues with doing a bulk b'' prefix insertion. One was that the added b characters would cause a lot of lines to grow beyond our length limits and we'd have to reformat code.
I wonder if their line length was arbitrarily 80chars or some silly serial terminal like limit.
> It is now 2020 and Python 2 support is now officially dead from the perspective of the Python language maintainers. Linux distributions are starting to rip out Python 2. Packages are dropping Python 2 support in new versions. The world is moving to Python 3 only. But Mercurial still officially supports Python 2
To me it doesn't matter what pain points there were between 2/3, or that it was even python.
That is just the classic way any modernization effort fails. IMHO those failures are almost completely tool agnostic and are cultural failures.
Hindsight is 20/20 but that article definitely makes me question the technical leadership of the project. They chose to write a source transformer (which introduced its own set of issues) rather than update string literals to use b'' syntax because they didn't want contributors to have to learn how to use python 3? And because they didn't want lines to be too long? And because it would break change attribution for the lines in question? None of those reasons sound compelling to me at all, but the author presents them as the correct decision.
Very interesting article.
I too was rather upset about the Python 2->3 shenanigans and I was working on much smaller projects.
Python continued growing fast during the 2 to 3 transition, it was nowhere near dying. It was one reason it took so long, people were starting new Python 2 projects 5 years after Python 3 was released. Only around 2017/2018 the default for new projects kind of became Python 3.
Python 2 was used for such a long time because many modules only worked on 2, which was a direct result of the compatibility being broken. There was a catch-22 for a long time that nobody would upgrade to 3 because nobody else would.
You could really make a business case study (well, a project management case study) out of the Python 2 -> 3 transition. It was a very well executed plan. It started with a clear definition of where they were headed (v3) with some good reasons for the technically minded. But the transition itself was really... really... slow.
It was methodical and deliberate, but slow.
But I think it really happened because developers wanted to move to 3. There was enough momentum and upside for moving to 3 that the Python core developers could keep the migration on track without having to drag people along from 2 -> 3 before they were ready. Making sure that the transition was optional for a long time helped tremendously.
I was quite happy working in Python 2 for a long time and only transitioned over to 3 for new projects or code that I thought would have a long lifetime. This was very much a reason why I moved to 3 instead of to another language.
At the same time, I'm not sure what language I would have switched to for the things I was using Python for... Perl was out as it had it's own disastrous migration. Ruby was an option, but never really hit the general-purpose scripting language mark for me.
It was a plan that obsoleted billions of dollars of working code and wasted huge amounts of time (undoubtedly multiple human lifetimes.)
Actual language standards that multiple stakeholders agree on are a much better approach.
Platforms should absorb pain, not multiply it across all developers that use the platform. (I wish Apple would learn this lesson.)
> It was a very well executed plan.
Uh.. You've started in the middle. Python 3.0, 3.1, and 3.2 were insufficiently compatible to support a migration. If not for the effort to reduce 2 to 3 incompatibility by shipping 2.7 and 3.3, 3 could really have failed. I'd say the initial plan was not so good but then the _replan_ after the first setbacks was good.
I never saw the initial versions as viable versions for production work. IIRC, neither did the authors. Part of what I think was so good about the plan was that it was a parallel track for so long. They didn’t start the process of sunsetting v2 until v3 was ready to take on the migration. The specific steps taken, versions released, that wasn’t what was so good IMO. It was the time scale. This was a good decade long transition. The fact that Python thought it would have that much time to make the transition was audacious, but it was going to take that long. And now we have a better language that has supported many more years of growth.
> Python 2 to 3 took a really long time
It took AdaCore so long to port the plugin system of the GNAT Studio (GPS) to Python 3 (which seems to be a fraction of the whole code base), that even conservative Debian had to remove the whole GNAT-GPS package.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082332
> There was always a clear way forward and people were actually moving.
I was always of the impression that people were very reluctant to move even though the benefits were clear and the movement not nearly as difficult as people claimed. But I still hear people complain about, for example, how you can't run CPython 2.x bytecode on a modern CPython runtime even though you can't run CPython 3.13 bytecode on a CPython 3.14 runtime, either and that hasn't slowed anyone down at all.
> the movement not nearly as difficult as people claimed.
Original was really rough because the core team had gone in the wrong direction on migration, and the Python io module was hell as well.
By 3.3-3.4 it was relatively smooth sailing but that took a lot of work from the community and core team both (reminder that Python 2.7 was released after 3.1, backporting a number of features to make compatibility easier, and old features were reintroduced as late as 3.5).
I started on 3.2 and found it reasonably smooth (dealing with encodings in 2.x was also not pleasant IMX if you also cared about universal newline support at the same time), but I will definitely cede that 3.0 and 3.1 were Not Ready.
I watched both of these at the time. FWIR Python took some learnings from the Perl experience and it was still close.
I agree
If anything might have killed python it was not python 3 per se but shipping a "beta" version of Py3 as 3.0
Python 3 only got usable really around 3.3 or maybe 3.4
Not sure why this was downvoted, 3.3 was when they started re-adding things that were removed in 3.0, to make supporting both 2 and 3 reasonable for libraries. I think it kept going in both 3.4 and 3.5 with more features, but the 3.3 restoration of the "u" string prefix is the one that I remember.
Not to dispute the overall premise that Perl 6 did enormous damage to Perl, I want to interrogate this a little bit:
> There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use because they still have momentum and lots of legacy things built in them. So being ugly or old isn’t enough of a factor for people to abandon something in droves.
Nothing forced anyone to abandon Perl 5 code, and I suspect most Perl 5 wasn't abandoned for its own sake; it was a Cambrian explosion of new greenfield projects rising out of the ashes of Web 1.0 that brought Python and Ruby and PHP to the forefront. It's just that a lot of the Perl 5 code out there in the world was quick and dirty CGI scripts that died naturally after the dotcom crash and as the web became more sophisticated.
My take is a lot of that Web 1.0 stuff was total spaghetti code, hardcoded to a table layout, full of injection holes, etc etc. (It was like everyone did my first CGI script x 100.) So in that sense Perl wasn't any different than classic ASP or cold fusion or etc, it became associated with bad legacy code. And because there was no 'Perl 6', people had to choose something else.
(There's stuff about the perl language, but that's probably secondary.)
Yea, Perl thrived while there was no real alternative.
PHP arrived and ate into it's web app use-cases. Modperl wasn't great for hosted environments, to say the least.
Python matured and started eating into it's systems use-cases and eventually the web use-cases as well. And was just so much easier to work with and learn.
Perl was left with no real niche where it really shined, except one-liners and making poetry I guess
>>Nothing forced anyone to abandon Perl 5 code, and I suspect most Perl 5 wasn't abandoned for its own sake;
Perl, Lisp, Haskell, Prolog etc.
I was there when Perl ruled the world, I used it myself to rule the world. The scene was always managers going to the C++/Java teams and asking them an estimate to a get a project done. They would often come back with timeline spanning 1 - 3 years.
Perl teams would get it done in like a week.
Needless to say most non-Perl programmers wanted Perl gone for this one reason alone. Too powerful, people who know how to use it make too much progress compared to everyone else. Smaller teams making larger progress shrinking the head counts, which top bosses didn't like.
Programming world is a sea of mediocrity, good things mostly don't make it here.
I got into Perl in the early 90s in the Perl4 days, watched the very weird but necessary Perl5 come into focus, then I saw Larry and the community in the 2000s get stars in their eyes and just throw it all away for the dream of Perl6.
The real issue is not just that Perl6 wasn’t backwards compatible, it was that Perl6 basically did not exist for real for many, many years. People got tired of waiting, and the lack of backwards compatibility did not help.
Also Perl6 was just more weird on top of weird from a mainstream perspective. Making it even harder to justify.
And killing Perl 5 in the process. If Perl would have kept going in its own pace and Perl 6 would have been named Rapture or Raku from day one, Perl would have been fine.
Nowadays when everyone and their dog (vcpkg) have a package system, it’s easy to overlook how magical CPAN was. A solution to the weirdest problem, just a package away.
CPAN and similar things like CTAN were simply phenomenal in a way that really is hard to explain today; since everything has it now.
It was a magical time.
If they hadn't done Perl 6 the way they did, it'd still be around. Perl 5 was fine but the impending doom gradually let it be overcome.
It's interesting because you can still find interviews of Larry online how Perl is the first postmodern programming language but for perl6 they came up with a very top-down, modernist project
I had a similar experience. It was so disappointing to watch them bike shed Perl 6 endlessly while Python was gradually taking over.
Even as a die-hard mod_perl fan, I never even tried Perl 6. The language had gone from the most concise and efficient way to process text streams to an incredibly complex OOP language that for some reason had an experimental Haskell implementation, its own custom VM and multiple compilers.
> JavaScript can only survive this because there’s no other option in a browser.
JS 100% respects compatibility, they even avoided some methods because some popular libraries in the past used to extend the Prototype for arrays
> it was a good decade before they even admitted Perl 6 might take longer than expected
I was there at OSCon when Larry announced Perl6, and that it would be "out by Christmas". And I was there the next year, when he was asked about that, and cheekily replied "well, we never specified _which_ Christmas."
> well, we never specified _which_ Christmas.
The wider Perl community adopted that, and for years it was a running joke that Perl 6 would be "out by Christmas."
Of course, people outside the Perl community didn't get the joke. They just perceived it as the Perl community making promises about release dates and then missing them. That was some self-inflicted damage.
The First World War was supposed to be over by Christmas. Is it possible that it was a deliberate reference?
You can break backwards compatibility, if you are careful.
In fact, Perl even had the tools to break backwards compatibility baked in from the v5 days.
I agree that Perl 6 is why perl died, but I think the thing that really killed it is what you mentioned. It was a completely different language that spend over a decade with a release date of "soon".
Who wants to work on a language that isn't being worked on because the next thing is AND where from what you know of the next thing everything will be a complete rewrite.
A completely different language, a decade of development to Perl 6, and Python eating its lunch in the meantime. Perl is often called a write only language, and there's Python with
If you were new to the field at that time, Python seemed like a no-brainer.Even as an experienced developer who even owned CPAN modules and was very familiar with the Unix ways, Python was a no-brainer.
I mention this on light of the article's claim that this has to do with "a new generation of programmers brought up on … I don’t know, Microsoft systems, Visual Basic and Java". No. The new languages that appeared were just so much much better.
When you have advantages that often come down to "it works great on a teletype over 150 baud" (read, compressed syntax, regex, etc) you will eventually be beaten by something that is easier to read at a glance.
Non-programmers read python and sometimes even Java and say "huh, this is something that could be figured out" - reading perl was reading line noise.
APL is probably one of the most powerful languages out there, but the characters in the syntax scare most away.
> The backwards incompatibility of Perl 6 absolutely killed Perl.
The insane lead time of Perl 6 to even get to a point of backwards incompatibility was it for me.
I'd started on an early version of perl 4 and went through the 5 transition and was excited about 6. For what seemed like "Duke Nukem Forever" time, and finally my fickleness drew me to other languages and frameworks.
I think more specifically it was the hesitance to move Perl 5 significantly forward in the meantime that caused the damage. That has been decidedly changed the last few years, with great strides being made. That time in between is lost, though.
This is the key - you need to cannibalize from the "new" for the "old" if you're making a grandiose change with no set release date. Perl 5 continuing to get some "back ported" improvements from Perl 6 would have kept it alive for quite a lot longer.
You run the risk of killing the new in the cradle, though, and often that scares people.
that's the way you wanna roll> For what seemed like "Duke Nukem Forever" time
Fun fact: The amount of time it took Perl 6 to come out after being announced was actually longer than the amount of time it took Duke Nukem Forever to come out after being announced
hah! How about "Star Citizen", then?
There are also a lot of things about Perl that prevented new developers from choosing it when other options were available.
I learned Python from reading a pocket language reference that just described the syntax and standard library, because the language was simple and easy to understand and everything made sense.
Conversely, I was trying to debug a script someone else ran and came across a line that said '$|++'; it was impossible to search for on the web, and when I asked on IRC the only answer I got was 'man perldoc' which also did not answer my question in any reasonable way.
For anyone wondering: `$|` is an alias for `$OUTPUT_AUTOFLUSH`; it defaults to 0 (line-buffered) but any non-zero value means 'flush output immediately'. Thus '$|++' changes 0 to 1 (or 1 to 2, etc), which means that '$|++' means 'turn off output buffering'. No one could be bothered to say that; if you had questions about the language you clearly didn't RTFM well enough so that became the default/only answer I ever saw.
Meanwhile, the PHP community was often welcoming and helpful to newcomers, despite most of them being bad at programming and giving bad advice, and the Python community produced a language that was so often self-explanatory that new user questions were more about how Python did things or asking about how to implement things they didn't realize were in the standard library.
So yeah, lots of things contributed to Perl's decline, but the community being a bunch of elitist toxic dicks sure didn't help matters and it meant that as the set of people looking to learn how to do programming on Linux grew past the neckbeards looking for any metric to show that they were better than other people then Perl's growth potential was finite.
Perl was not and still is not suitable for people who refuse to read the manual or tutorial.
Perl had and still has truly AMAZING documentation (and far better in perl 5 than Perl 6 - where the documentation's search function is regularly broken for example). And out of this world bring-up tutorials. But if the bar is at "I want to be up to speed after reading a short booklet" - well, that's not gonna work. For me I have programmed in perl for decades and I still get the occasional deep plunge in a feature area that I never used before... And the various docs and books still come through.
On top of that, Perl 5 had an amazing community ready to help - but understandably annoyed with constantly re-quoting the AMAZING documentation. It could have gone either way, it just went the way it did: experts present and ready to answer. But there too - if you expect the community to constantly answer the most basic questions, well, Perl was not for you.
As a tradeoff perhaps, that expert community also spent a lot of effort on the AMAZING module library.
Perl 5's thorough documentation, plus splendid course book, plus all the books, plus CPAN, PLUS the expert help producing fantastic rabbit holes to learn more about your PROFESSIONAL MEDIUM. THAT was the reason for choosing perl.
If anything, newcomers don't go to the documentation because they are not aware that documentation can be THAT good. That was, still is, a marketing error.
That's an interesting observation - and my recollection is that the perl heyday was just about before the Googlefication of the world; certainly before stacked overflowing.
Grab a snippet of Java or Python and you can google it pretty easily, grab some line noise from perl and you would first need something to translate it into idiomatic text - search engines would search for "OUTPUT_AUTOFLUSH" but would often discard things like "$|++"
I remember learning my use of perl from a red book - probably "Perl 5 by Example" - everything was in books back then, and you read them. Now you learn programming via searches and LLMs, so the languages that win going forward are going to be the ones optimized for that.
> search engines would search for "OUTPUT_AUTOFLUSH" but would often discard things like "$|++"
Out of curiosity, I tried
in DDG and Google. DDG returned nothing, but Google led with "perl $|=1; What is this?", and "Perl, what does $|++ do?", both from Stack Overflow. Search like it's 2014, eh? I don't have a time machine, but I'm pretty sure that quoting would've worked ten years ago, too.> the only answer I got was 'man perldoc'
When I asked a question on the PERL Usenet group in the 90s, I used the word "newbie" to describe my skill level. I got an automated email explaining why I shouldn't use that word.
> when I asked on IRC the only answer I got was 'man perldoc'
Your overall point notwithstanding, this was just bad advice. What you want is `man perlvar` (or equivalently `perldoc perlvar`) which documents this and other predefined variables:
Also, `man perl` gives a great overview of the extensive number of Perl-related manpages. I think any person that starts from `man perl` will be able to answer a lot of their questions, but part of the problem was that around the millennium, people stopped reading man-pages, and started looking for information on the web. perl was one of those old-school tools that were documented extensively in man-pages, but past 1995 ~nobody bothered to read man-pages anymore.Let me respectfully disagree.
would tell one needs to use -v key to learn about a var. And consequently would tell everything one needs to know about $|So it was actually reasonable advice.
Fair enough, but I think the first part of the advice would be a lot more helpful if it included the second part too. It's the intermediate step that turns people off: why do I need to learn about `perldoc` when I asked about `$|`? (And that's assuming the question asker is familiar with man-pages to begin with, otherwise, you need to read `man man` first!) It feels like you're sending them off on a wild goose chase, even if that's not your intent.
In the millennial web forum world, a n00b would ask "what does $| do?" and the answer would be "it disables output buffering", which is what the n00b wanted to know in the first place. It's the Stack Overflow model of giving men fish, instead of teaching them how to fish.
And in today's LLM-powered world that's only more true. If you ask ChatGPT "In a Perl script, what does $|++ do?" it will immediately give you a correct and concise answer, not make you read `man perldoc` first.
Yes, it would look and work better if presented with an explanation like "you can find any var description by using...". But as I commented already in another thread there was a widespread belief in 90s-00s that users who ask about already documented pieces are being uncivil, not vice versa. So it's not about Perl community per se. The same was norm in many Linux fora, for example.
RTFM might be reasonable advice, but its not "welcoming" advice.
I remember being very enthusiastic about helping people on, say, Stack Overflow. It didn’t take much extra effort to be nice and made me happy.
But I also burned out relatively quickly. I’d happily answer new questions nicely, but the third or fourth time I saw the same question I spent much less effort to give a welcoming answer than I had the first time I saw it.
Of course, getting the same question repeatedly may suggest something should be redesigned.
I don’t know any good way to keep helpful volunteers helpful for a long time. The best idea I have is constantly recruiting new experts to continually replace the ones that burn out and chase off newbies.
> getting the same question repeatedly may suggest something should be redesigned
Yes! There was a lesson in that and we all missed it. That was probably one of the failings of perl. It ran into a generation of people who never knew about "man pages", or couldn't read (jk - but only somewhat: for some people reading is very hard because various flavors of ADHD, dyslexia, executive disfunction, whatever) and the man page is then useless, or they go to google first and '$|++' failed (because google was raised on python).
Better marketing of the documentation would have helped.
I would say "we'll do better next time" but then perl 6... I'm not happy with perl 6 documentation. There is a lot of it - no problem there. But it insists on living online which necessitates a hosted search function. Which is always broken. And there is still no "local doc" solution.
man I hate that always online stuff. why isn't there the comprehensive man pages thing for perl 6? rhetorical question tho, I don't have much interest in perl 6.
If they specified ‘perldoc -v $|’ instead of just ‘man perldoc’ I’d have been thankful for that as the entire response. It’s literally a pointer to where the answer is and to how to use the canonical tool to find it.
I agree in general (and already commented on this). But some people believe it's like giving fish instead of fishing rod. And I think it was prevalent idea in tech circles during 90s-00s that people who don't read that fm waste other participants time, and needlessly multiply forum topics or extend conversation history. Which was seen as uncivil behavior in those times.
Yep, especially when so many instances of TFM were awful. Perl's docs were fantastic, or so at least I thought at the time, but they were the first large open source project docs I devoured. I can imagine someone coming from another language not even considering just looking at the man page because they were used to awful documentation.
You are right, Perl's docs are so unusually good that newcomers can't believe they don't need the internet to find clear answers, and go searching/asking anyway, sometimes in wrong places.
FreeBSD has the same problem: plenty of its new exploring users dismiss the most well-intentioned advice to read its excellent Handbook as a sort of joke.
I’ve seen that one firsthand! “I want to do a thing.” “That’s in chapter 5 of the handbook.” “Oh cool. Is there a substack or something that explains it?”
How would I know that $| is a var? It could be an operator, or a function, or a directive.
There's no space for doubts at all. If it starts with $ then it's a scalar variable name. It's a very basic rule in Perl. Like any Perl tutorial would mention it within a few paragraphs from the start.
So then wouldn't that make $|++ the variable name?
Smokey, this is not 'Nam! This is <Perl>, there are rules!
'$' guarantees a scalar. Then it either alphanumeric id, or a single non-alphanumeric symbol. And the latter means you deal with a 'special' var which with 100% certainty has a documentation entry.
so they should have written that. Next you're going to tell me man man is reasonable advice
That variable in particular gets covered in the Llama book as well. Anyone serious about learning perl in the 90's had at least one of the Camel or Llama books.
Golly
There, the problem illustrated
"You are not serrious" is a downright hostile attitude
"man perldoc" as an answer can be translated as "f*^&%k off you stupid...."
A professional medium might have been gate-kept being paying coursework. Perl was not: the super-complete documentation was right there, in the distribution; the remarkably intelligently written course book was right there on everyone's shelves and in your local public library; the in-depth books same thing; And quickly enough even free on the net; the expert-built module library was all there to use and study; the experts were giving their time freely, writing deep dive articles at the simple prompt of worthy questions in addition to columns on topics which I guess were not getting enough questions.
For a professional medium, the only lack that I can tell is from a marketing point of view: installing the distribution for example, probably did not highlight enough how extensive the documentation was.
> f*^&%k off
Hey you're writing perl already! ;)
Sorry for being salty earlier, but learning a language still takes at least a day or two of solid reading of the official manuals. https://perldoc.perl.org if you want a web version.
This is exactly the point.
There was a fifteen year period where the best way of finding out what something meant in a programming language was to Google it. Pre-AI, post the predominance of newsgroups and offline documentation.
Try googling "$|++". It just doesn't work. Never has.
Now Google "file.flush". First hit is the answer you need on SO.
You did not need to google anything. The complete documentation was right there, next to the interpreter, on your machine. Ready for scanning and reading from top to bottom; and broken in sections that were actually relevant; and ready to search in bulk if you prefered with whichever local search tool you cared for.
No need for google. (And google was run by python fans; probably saw no need to support searching for '$|++'.)
And I notice "post the predominance of offline doc". Well that's one problem right there: As of 2025, there is still nothing that beats perl 5 docs as ~260 man pages. Probably LLM-based AI is getting there, at least for people who have difficulty with text. But for the rest of us, it's VERY useful to know that there is solid (offline) doc.
Also to be fair, a modern Perl app doesn't even need to use `$|++` since the framework, even if it's raw Plack, will manage output flushing for you since you're no longer banging on raw stdout. I'd say Perl suffers from an even worse problem of legacy tutorials than PHP, but the size of PHP's userbase and thus sheer number of bad tutorials makes it worse there.
chromatic's https://modernperlbooks.com site is nearly unmaintained now, but still contains some good links to tutorials and whatnot on the obvious subject. Including a pretty recent retrospective: https://outspeaking.com/words-of-technology/why-perl-didnt-w...
Right, yes, exactly.
I disagree, at least when it comes to the web (of those days). What's the point of rewriting what's already well- and accurately-written in the docs? What better job are the people on that message board going to do with regards to such a small, specific syntax feature? The point of those "communities" wasn't to answer questions like "what is this variable?" but rather to have actual discussions on the language, such as how to structure applications, design patterns, projects, etc. Imagine trying to build an online community for this purpose, only to spend your days answering the most basic questions possible that were already explained many times before.
Eventually, a website more tailored to such questions was created - Stack Overflow - and there things were very different than in subject-specific communities: there was no "community", there were no discussions, just a big mess of questions. It had a purpose and it served it well. Now it's dying too because of LLMs, but I digress.
Now, in a different scenario, say a colleague asking you that question at work, a direct answer is warranted, but without letting the colleague know that this information and a lot more is a just a few keypresses away would be a wasted opportunity, and not particularly a good way to help that colleague progress.
You can only spoon feed people so much. At a certain point relying on other people to just give you the answer every time you don't know something is lazy. It's like you have no respect for their time.
Golly. There are still some who think it is ok to be rude to newbies.
$|++ is arcane to anyone not steeped in Perl
The newbies could be warmly welcomed and shown respect.
But no, RTFM.
That is rude to somebody drowning in newness. If you do not want to answer their question, then don't. But some people seem to get a kick out of being rude to weaker people
All the times it happened to me, back in the '90s this made life really much harder than it needed to be.
For all the ones who bum me out
For all the ones who fill my head with doubt
For all the squares who get me pissed
You've made my shitlist
>Golly. There are still some who think it is ok to be rude to newbies.
the entire tech industry is driven by humans and we're really bad at everything. once the AIs take over things should be much better, except for the occasional hallucination.
> made life really much harder than it needed to be
If only you had read the manual...
Seriously though, of course I wasn't advocating for rudeness, and trust me, I remember how rude some people were back then in tech-related boards, this was not a unique Perl thing. I'm advocating for pointing people to the sources of information they're looking for.
> You've made my shitlist
Well then I hope it's posted somewhere I can refer to at will so that I don't have to ask you on a message board like a noob.
The problem is with man pages themselves. You shouldn't have to read 100% of something to find 0.1% of something. In fact, this concept is covered extensively in CS theory about sorting. Reading a manpage is less efficient than asking someone who already knows.
Only locally, only for you, and only short term. You are wasting the time of the person you are asking, and you are learning absolutely nothing about the context of the answer. When the next question arises, you won't even know where to look, you will only continue wasting other peoples' time.
That's a false assumption that the man page even has the info you need. There are channels to write bugs against code, but almost nothing to file bugs against man pages. That's not even a concept to most people, that it's a bug when you apply a use case (say, to apply eui-64 to SLAAC in IPv6 in order to generate a consistent address) and cannot find the information using the man page. If you filed a bug that the man pages failed you nobody would fix it because it's not sexy, glamorous work. Its easier to tell someone to RTFM.
In this case, you would have to already know about the existence of eui-64 to know that is what you want. I've seen this many times, you have to know what the thing is already, or know what the answer is to your problem, in order to find it in the man page.
Total waste of my time. I don't care if it's free or was created by volunteers, that isn't absolution of criticism when it represents something and fails to deliver it.
Nonetheless, you are expecting other people to know the manpage and read it for you. That is a game you may be able to play with paid support, but usually not even there: They will be more wordy and polite, but in essence tell you to RTFM as well.
Bugs in Perl modules that are documentation related are normal bugreports and patches in the normal patch flow because documentation is embedded as POD within the source code.
Your example is very specific and weird (and maybe not even Perl-related). From which you deduce that it is OK to waste the time of volunteers because once one manpage failed you and you decided to never read any manpages again. You only seem to care about your own time, not anyone else's. That is not how anything works on this planet, either you deal with volunteers, where you have to make them care about your query by being considerate, friendly and respect their time as well as you would like yours respected. Or you are dealing with paid support, in which case you have to make them care by paying them for their time by the hour.
There are some manpages which are too long, and cumbersome but it's not a widespread problem I believe. In particular man perldoc is laconic and on point.
I don't think that RTFM is the best form to answer, but those who auto-reject "man" as an answer are definitely missing something important
The trick is to already know how to use regexes to make searching the manpages easier! But you really have to nail down the rules for escaping when you want to search for perl's gnarliest sigil magic.
The man pages were broken into competent sections over multiple man pages. About 260 of them on this machine (not really: there is a change-tracking man page per release recently.) The 1st man page is a very compact index to them.
After that, each section is long but very searchable.
But I can see how many people never even noticed."Man page? what's that? what for?"
But if every user is expected to read the entire manual cover-to-over before asking a question about a four-character operator, what's the point of dividing it into sections?
I know you are not serious but let's go with it anyway. Since we have to be welcoming to newbies :-) Not expected to read cover to cover. Cover to cover would be the tutorial / course work. And even then in a layered language like perl 5, the later chapters only when needed. Layered: the language and coursework is written to add one layer of the language after the previous ones. So you can start writing things that do function after just the first layer.
Expected to know it's there, navigate through it to find the operators or system variables and that you can search through the thing. There are ~260 perl man pages on this computer - not expected to read them. For damn sure expected to use them.
Do read one more section from top to bottom now and then - if the thing is the one fundamental tool in your job!
But that's what the ancestor was trying to do. Then he ran into a symbol he hadn't gotten to yet, asked about it, and got flamed for not reading the full manual!
> flamed for not reading the full manual!
It was not for not reading the full manual. It was for not using the manual. Somewhere between "not at all", "not competently", "not persistently". And he was pointed to a perl-specific tool which is made for searching the doc. Not the same thing?
And he/they had missed an entire category of symbols. That none of the responses pointed at - their bad on that. That is, all these symbols are described in the same manual section. And used in illustrative examples all over the place. They are not exactly a deep hidden thing.
Also, regarding "flamed". No. Not really. They were handed the same response that countless other questions were getting. Anyone frequenting these forums saw them countless times. It is quite possible that it was their first time on that forum / chat and then that the answer was shocking and traumatic. Yes to that. So that in hindsight, the standard response should have included a pointer to a "how to use the doc" doc. That would have helped. Since it was a generation was seemed unaware of the man pages.
The problem is the implicit assumption that you can throw an entire book at someone and expect them to be able to figure out where to look for each piece of information in it without them knowing beforehand what things even are. If someone hasn't ever seen a variable like `$|` before, it's not necessarily going to be obvious to them what it is, and without knowing how to classify it, they aren't going to know how to tell what chapter it's described in. You're defining the bar for someone to be able to ask a question as high enough that they spent enough time reading through everything to be able to identify it. That's going to be fine for some people, but not everyone learns the same way, and when some people learn better a different way than you, it's not because they're stupid or lazy, but because there's just a lot of variety in what works well or doesn't for people.
Of course, you aren't under any obligation to spend time helping people who you don't want to, but if a community as a whole reacts this way when someone asks a question, they're making the bet that the there are enough people who are similar enough to them to sustain things in the future. Given that this both happened years ago to the parent commenter and now again when they tell the story again, it's not really that hard to believe that this might have been common enough that a lot of people experienced it. The entire point of this thread is discussing why Perl has faltered, and your explanation in the last paragraph comes across as basically saying "kids these days..." in slightly different words. I'd argue that even if the kids loved man pages, having a condescending attitude towards them would probably still come through in other ways, and that would have had pretty much the same effect.
I am agreeing with you that there was a mismatch between the expectations on using the elaborate documentation in its various forms and the tutorials and the stellar course - and a large set of potential users. Nobody expected "the entire book" but perl 5's rise came at the time when many stopped reading man pages, and many projects stopped providing them.
I agree with you that this probably was a contributor in some people giving up perl quickly. For python or php.
Like I mentioned elsewhere, for people for whom using a book would be a barrier - perl would have been a poor choice anyway. You can't program in perl without using the man pages and books. It's a large language, with lots of features purposely made less visible to the newcomer.
In addition, many people were exposed to perl from web scripts. And it was sooo tempting to just paste in a perl script, and then want to modify it, without spending any time on learning the language. Perl makes that frustrating (and compensates with a stellar course book). I still defend perl by arguing that (in perl) there is no point in discussing what $| might mean even before having covered the basics, for example sigils. The course book is layered, and for good reason: to let you write a program in useful order, fundamentals first. The special variables come up fairly early but then again the course book had an extensive index which includes these special variables first in a symbol section, and then again in the alphabetical order for their wordy version $| or $OUTPUT_AUTOFLUSH. I'm not trying to beat you over the head with the manual. Just pointing out that the course book was throrough and intelligently written.
I'll point out that throwing a question at a forum without poking around it a little to figure out the local mores - well, still now, that will get you barked at. Lesson: Forums would do well to provide a more useful paste-in than "RTFM" - ready to go for their users. Instead of "RTFM". At least if they want to foster adoption. Does any forum do that particiularly well, that you have noticed? Most discords for example, do NOT do that well: it's possible to create stickies and they are really not visible. So people create onboarding documents which then get too long and get skipped. A problem not solved there.
This comment kind of epitomizes the way the Perl community works, to be honest.
Sorry for the bad experience you had, I believe it's always better to be kind to strangers on those global nets. But TBH perldoc would really work very well for you.
This is so spot on. You can't google line noise, and that mattered before LLMs. And everything else you said.
> Both Bill Gates and Linus understand backwards compatibility as a sacrosanct principle.
I will always bang the drum for Java for doing this well. Making changes to a heavily used language is _hard_. Sure, the speed of progress can be slow, but Java has managed to introduce major improvements (and deprecations) without causing a schism. That deserves respect.
I feel like time and again language designers don't properly uphold backwards compatibility as a high enough priority, to their and their users detriment.
My team has recently ported 14 Ruby services along with over 50 separate Gem libraries from ruby2 to ruby3 where THEY CHANGED HOW FUNCTIONS INTERPRET ARGUMENTS! Older code run on newer runtimes _change behavior_ for the same code by treating splatted arguments differently, which was _very_ annoying to figure out and reason over for codebases that _heavily_ used '*' splatted arguments.
I feel like folks need to take page from Java's book and maintain backwards compatibility as a core tenet of their language. I've done perl4 -> perl5 -> raku, python2 -> python3, ruby2 -> ruby3, and rewriten a handful of c++, rust and node applications because everything in those landscapes seems to be in constant flux...
I just want to write software that will continue to work after it's been written, without having to use an older CVE-ridden language runtime every time. From personal experience, only java seems to 'get it.' (I'm sure there are others that do get it, but sadly I've had little opportunity to use them.)
> from Java's book and maintain backwards compatibility
Didn't they start breaking things between Java 8 and 9? Modules, Reflection Access, JavaEE, ... .
Nope, the closest thing to a a breaking javalang change is adding new keywords like var. Outside of the language itself, java's standard libraries have undergone some depreciations and packaging moves (moving javafx, etc.), but absolutely nothing like breaking core language constructs, syntax or behaviors across revisions. I would expect standard libraries to have some deprecations across a 20+ year span.
However, I'm of the opinion that "standard libraries" should be much more minimalist and than javas: move as much as you can into a "core" library that isn't necessarily part of the language, just an optional runtime component following semver so you can be sure pinning a major version will work for essentially forever. Java isn't perfect in this regard, but it sure as hell better than what perl, ruby and python have done in significantly less time than javas...
> Python only just barely survived the jump from 2 to 3.
In the timeframe we're talking here (late 1990s), that transition was Python1 to Python2! A couple Linux distributions were on Python 1.5.2 for a very, very long time. All y'all forget that what Guido, et al. did for the Python 2 to Python 3 transition was informed by the grief they hit in the Python 1 to Python 2 transition!
I would argue that really "What killed Perl" was that people started writing bigger scripts than one-liners. Perl has a well-deserved reputation for being a "Write Only(tm)" language. Python (and really just about every scripting language of the time) was simply better for containing complexity and easier for a newbie to understand.
I remember taking printouts of Perl and Python scripts for the same task to job interviews. The Perl one always had some surprise for the interviewer no matter how hard I tried to remove them. The Python one ... was simply straightforward.
If you had a hard, one-time problem, you always went to the perl wizard; he could do anything to anything given a bit of time.
Even build an entire web-based GUI for a product.
But eventually you realized that if you wanted to reuse the code, or have others work on it, the downsides of Python began to pale.
> There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use
What's an example of a language that's as bad as Perl, that's used as widely as Perl was, that's still in use today?
Perl died because everyone who mattered knew it was a bad language, knew it had to undergo drastic changes, but that essentially meant implementing a new language.
Perl 6 was the symptom, not the cause.
---
Note: by "bad language", I mean bad for anything much beyond the kind of thing you might use awk for. It was bad not because of subjective aesthetic issues, but because it was difficult to maintain non-trivial code bases. Its "write only" reputation was well-deserved - the original author of a non-trivial Perl program might be able to maintain it, but once a team is involved, forget it.
You say it was a "bad language" for projects of any real size. But I've worked on large systems written in perl maintained by multiple teams. Perl wasn't the source of our difficulties.
The real issue was ugly code that was in the product when it was acquired--you can write 2000 line methods in any language if you are cursed enough. Believe me, if you do this, you will be cursed.
We dealt with the flexibility of the language by defining clear guidelines on what approaches were recommended and what misfeatures were banned.
I'd go so far as to argue that the expressiveness and flexibility of the language was an asset that helped us in our refactoring. For example, we built instrumentation that took advantage of Perl's unusual semantics for dynamic "local" variables to create flexible instrumentation that could have log levels enabled based on the call stack--if you turned on aggressive logging in function A, it would propagate to A's calls into functions B and C, while other calls to B and C would be logged at normal levels.
Yes, it's possible to do this sort of thing in other languages using a singleton that tracks logging context, but the dynamic scoping gave us the tools we needed to build something powerful with only a small amount of clear, commented code.
Interesting to hear that perspective. But you touched on where I'm coming from:
> The real issue was ugly code that was in the product when it was acquired
IME, this was the norm for Perl projects, not the exception. And you explain the reason for that:
> We dealt with the flexibility of the language by defining clear guidelines on what approaches were recommended and what misfeatures were banned.
Yes, it's true that a disciplined, mature, skilled team can write good code in any mainstream language. But in practice, there are far more teams that lack enough of those qualities, that using what I'm calling a bad language will contribute to them producing hard to maintain, buggy code.
If you're defining a subset of a language as being good, you're proving the point about the overall language not being good. This is why Perl failed - because its real-world use more often than not produced poor outcomes.
> Yes, it's possible to do this sort of thing in other languages using a singleton that tracks logging context
That doesn't sound like the right approach - it sounds like you really want the opposite of a singleton. In most languages, you'd just pass a different logger instance, either as an argument or in an object field.
> What's an example of a language that's as bad as Perl, that's used as widely as Perl was, that's still in use today?
PHP? I don't know how widely it's still used, but I'd guess it's more widely used than Perl. Also, PHP is not "as bad" as Perl. It's much, much, much worse. It's Perl without the charm.
I think PHP in general is still popular... even though some of the devs switch to Go...
I think it really comes down to, do new young users want to use your language? I don't think perl5 vs perl6 scared off those users. I think the language design is outdated for what people want from computers today.
Indeed. Coming from UNIX tools (sed/awk/sh/grep/tr etc), perl had a lot of appeal and almost intuitive syntax - alternatives in the '80s being C, awk, or if you were unlucky, FORTRAN IV without string type :-). The benefit of having a single language with all of the functionality of these tools was amazing at the time and ability to use familiar syntax was a benefit. However expectations for programming languages grew somewhat since...
What we can learn is: evolution is a better choice over revolution given that there's no extreme internal or external pressure.
You can co-exist. That's the best path forward for breaks IMO.
Rust does this with "editions". That's where they can make breaks to the language. 2021 can still call 2017 edition code.
Perl actually had this as well with Perl 5. You could specify the version of the perl file and work from there.
Why they didn't do that with 6 was entirely bizarre. They basically promised to throw out all of CPAN with the next perl version.
To be fair, you still have a choice to start new projects in (still progressing) perl 5 or in perl 6. Perl 5 is not abandonned.
I second your perplexity on perl 6 vs CPAN. I still don't get it. It's still a problem.
> The backwards incompatibility of Perl 6 absolutely killed Perl.
I think the backwards incompatibility was a minor issue compared to how long it took for Perl 6 to be released. It was eighteen years from the announcement to the first (just barely) usable release. And for a lot of that time, I was hearing tech leads say things like "we don't want to start this project in Perl 5 if Perl 6 is just around the corner."
At some point, they changed the narrative from "Perl 6 is the next version of Perl" to "Perl 6 is a sister language to Perl" - but they should have renamed it at that point instead of waiting another 5 years.
It's worth remembering that the Perl 6 project was started because Perl usage was stagnating. But the project was so badly managed that it killed off both Perl 5 and Perl 6 (now renamed Raku).
I don't think it was just the backwards incompatibility on its own. I think perl would have had a much better chance if perl 6 had been ready sooner. The long period of time between perl 5 development stopping and perl 6/Raku being ready for production made the transition much, much rougher than if perl 6 was ready from the beginning, or if perl 5 development had continued, and moved closer to what perl 6 would be while perl 6 was still in the works.
> There are many languages still in use today that have all kinds of warts and ugliness,
Right, but there aren't many with the kind of ugliness associated with real-world Perl code.
Well, what Perl code is not real-world? And by ugly you mean what - not verbose or what? Something is ugly for ones, but nice to others. I doubt that really is a factor driving a demise of language, otherwise features like regexes would be non-existent today.
It's just a completely different model. Scalar context vs list context. @x returning length vs $x[0] accessing the list. It has a logic but it's its own logic.
Not unlike Rust's borrow checker but at least with Rust you know what you're being promised.
> It has a logic but it's its own logic.
Which is covered in the very first section of the course book? Yes it has its own logic. So do lots of programming languages.
How far do we need to take "not reading the doc"? That the very first chapter is too far? People who gave up on perl because of that... really would not have survived the rest of the course anyway?
You can learn Python, PHP and (a bit less) Ruby without ever touching a book, and definitely you can skip over the first chapter if you're an experienced programmer.
There must be a reason why they made sigils more "traditional" in Perl 6, for example.
> People who gave up on perl because of that... really would not have survived the rest of the course anyway?
I didn't give up on it, I just didn't feel the need to stick with it. I switched to something else that required less of a context switch when going back, awk or jq or Python.
Now, jq is something that throws me off every time I use it. But it's a completely different processing model, whereas lists and hashes are not specific to Perl.
> I just didn't feel the need to stick with it.
So, to touch on that, no contest that for a while now, you can have a well paying job only writing python. (And perhaps even never going through a formal course on it.) That has worked for many people.
> There must be a reason why they made sigils more "traditional" in Perl 6, for example.
Eh. Sigils are even more present / visible in perl 6. And other compact notation devices. All the way to making up your own unicode-based line noise when it serves. Which it does.
Yes, I didn't say that sigils went away. But for example in Perl 6 lists are @ whether you declare or access them, instead of the sigil changing depending on what you want to get out of the expressions. It says it in one of the first apocalypses even that people "found it a bit weird": https://metacpan.org/release/AUTRIJUS/Perl6-Bible-0.30/view/...
And at least with Rust, even if you don't love it, you can appreciate that there's a compelling reason for it to be that way. I wrote a lot of Perl, but never reached the aha moment where I understand why its sigils were so deliberately odd.
They were inherited from even older languages and meant pretty much the same thing there.
https://en.wikipedia.org/wiki/AWK#Match_pattern_from_command...
The $ notation for a variable in bash and awk... and BASIC... One might make the claim that EWD498 was correct... https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498...> It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
https://www.perl.com/pub/2007/12/06/soto-11.html/
> Now, however it was initially intended, I think BASIC turned out to be one of the first major scripting languages, especially the extended version that DEC put onto its minicomputers called BASIC/PLUS, which happily included recursive functions with arguments. I started out as a BASIC programmer. Some people would say that I’m permanently damaged. Some people are undoubtedly right.
... but it wasn't without previous examples that Perl went the way that it did with sigils.
I'm familiar with those sigils from various places. Me on my childhood C64: "What does 'B dollar sign' mean?". It just boggles my mind that someone writing a brand new programming language would use them when there were English-like alternatives (like `my foo = keys barHash`). It was sometimes hard to remember what [sigil][name] was going to if you didn't already remember what [name]'s, erm, inherent type?, was. Like is $foo going to give me the string that was already in $foo, or perhaps the number of (occupied buckets)/(total buckets) if $foo is really a hash?
I was able to reason my way through these things and had luck writing reasonably large Perl programs. It did absolutely zero to help make devs' lives easier, though.
In 1987, when your audience of bash and awk and sed users was looking for a language to bring those together and were familiar with them... why wouldn't you use them?
I would also contend that given the tools at the time (vt100 terminals without syntax highlighting being prevalent systems) sigils made it easier to write more on a line, provided easier visual recognition (for those familiar with the language) about the syntax, and provided for a more easily written lexer.
As a very long-time Perl developer and FOSS contributor, I think this blog post is incorrect about whether Perl 6/Raku was a factor in Perl's decline. I think Perl 6/Raku did a few things that hurt Perl 5:
1. It pulled away folks who would otherwise have spent time improving Perl 5 (either the core or via modules).
2. It discouraged significant changes to the Perl 5 language, since many people figured that it wasn't worth it with Perl 6 just around the corner.
3. It confused CTO/VP Eng types, some of whom thought that they shouldn't invest in Perl 5, since Perl 6 was coming soon. I've heard multiple people in the Perl community discuss hearing this directly from execs.
Of course, hindsight is 20/20 and all that.
Also, even if Perl 6 had never happened the way it did and instead we'd just had smaller evolutions of the language in major versions, I think usage would still have shrunk over time.
A lot of people just dislike Perl's weird syntax and behavior. Many of those people were in a position to teach undergrads, and they chose to use Python and Java.
And other languages have improved a lot or been created in the past 20+ years. Java has gotten way better, as has Python. JavaScript went from "terribly browser-only language" to "much less terrible run anywhere language" with a huge ecosystem. And Go came along and provided an aggressively mediocre but very usable strongly typed language with super-fast builds and easy deploys.
Edit: Also PHP was a huge factor in displacing Perl for the quick and dirty web app on hosted services. It was super easy to deploy and ran way faster than Perl without mod_perl. Using mod_perl generally wasn't possible on shared hosting, which was very common back in the days before everyone got their own VM.
All of those things would still have eaten some of Perl's lunch.
I think this is mostly the correct take. Perl's strength is that it was really good and quick and dirty one-offs, especially with text manipulation. This made it particularly popular with UNIX sysadmins and sometimes network admins. This was helped by the fact that CPAN made it easy to share a lot of these, which added to its popularity (it can't be overstated how revolutionary CPAN was).
The 1980s/1990s was full of many different data formats in a time before XML/JSON, often by long dead companies. Many a tech person was in a situation where "Oh fuck, how do I get this data out of some obscure database from some dead company from Boston that only ran on SCO UNIX into SAP/Oracle/etc" only to see somebody else already done it and made a CPAN module.
But stories like that became less common as DBs converged into a few players.
Yeah i'll say, even to this day, when I need a quick script and bash just isn't doing it for me I'll just write it in the same perl I used regularly as far back as 1998... but it never goes further than that. If I have to take that script and build it into anything that will ever leave my laptop it's going to get rewritten in something else (probably golang since it is universal on my team).
> quick and dirty one-offs,
Then used for huge GUI apps that run slow like a wet week, unreliably
The same thing is happening with Python.
I would also say -- in the late 90s, Perl's claim to fame was that it had CPAN. At the time, CPAN was revolutionary: a big, centralized repo of open-source libraries, which you could install with a single command.
Now, of course, that's a common and maybe even expected thing for a library to have: Python has Pypi, Javascript has NPM, etc.
And the whole culture around CPAN, too, with the likes of Module::Build and Test::Harness and the strong expectations around POD documents. Nothing like that existed for the other scripting languages of the time.
There was a well-trodden path from writing a hacky one-off script to deal with a specific task, to realising "hey! this might be useful for others too!" and trying to make it a bit more generic, to checking in with your local Perl Mongers for advice, to turning it into a well-tested, well-documented CPAN module.
That was the route I followed as an early-career sysadmin in the dying days of the dotcom boom - it helped me take on much more of an "engineering" mindset, and was an important foundation for my later career.
I can't have written more than a few dozen lines of Perl in the last 15 years, but do I owe that community and culture a lot.
Tcl/Tk is still behind,
9.0 has really pushed some big game changes. Sure it's a dinosaur's language from beyond times but still has it uses.
I would pick TCL over Python any day.
I love tcl. My absolute favorite thing about it is that `man tcl` [1] gives a dozen paragraphs that completely describe the language itself. Its simplicity always astounded me since it seems really simplistic but at some level it’s just as malleable as lisp. I wish it had caught on more (outside the hardware community which seems to have fully embraced it).
[1] https://www.tcl-lang.org/man/tcl9.0/TclCmd/Tcl.html
Tcl is magic.
Ashok's book is an excellent source of information too.
I was a Perl programmer from the early 1990s until into the 2000s and I mostly agree with you. It was a variety of factors.
The point where I disagree is I think Perl 6/Raku played a significant role in Perl's decline. It really gave me the perception that they were rudderless and that Perl probably had no future.
Other than that, I absolutely loved Perl. I love the language. It's super expressive. I never took a liking to CPAN. And I wonder if it could make a comeback given better dependency management.
I think Perl with tooling similar to uv would cause me to switch back today.
> The point where I disagree is I think Perl 6/Raku played a significant role in Perl's decline. It really gave me the perception that they were rudderless and that Perl probably had no future.
I assume you disagree with the blog post, not with my comment, since this is exactly what my comment says too!
Have you tried cpanm?
Between perlbrew and cpanm it's pretty easy to have multiple perl installs with different versions and quite simple to manage your dependencies.
Carton (manage and bundle your perl modules based on lock files) and Pinto (easily run your own private CPAN) provided the icing on the cake that made things really powerful.
I miss working in Perl, but the job market has pulled me in other directions.
This combined with a cpanfile is how I rescued someone else's workshop from being an "Install these missing dependencies" session to being back on track in 3 minutes with "Here's this file, run 'cpanm --installdeps --notest .'"
https://metacpan.org/pod/cpanfile
You mention it last, but I think PHP was most of it. PHP was the first and best-integrated technology for this world, which was huge and impactful. The "center of thought" in the text processing problem area moved hard to web development. And so the ideas about what needs to be improved or changed rapidly centered themselves around "Things PHP Did Badly". And that begat Ruby and Node, not a fixed-up Perl.
Perl remained (and remains!) eminently useful in its original domain of Unix system automation glue and ad-hoc text analysis. But it was denied a path to the future by PHP, and by the time PHP was itself replaced it was too late.
Finally everyone else (python in particular) sorta caught up to the "clever systems glue" feature set, and the world moved on entirely. Perl is mostly forgotten now except by those of us who lived it.
Great point! Confluence of simultaneous factors.
PERL tripped over it's own feet (too clever, line-noise, unmaintainable).
Java(TM) being "guaranteed to be business-like" sucked the serious use cases away.
PHP was easier to grok, had "editable man pages" (ie: comment forum attached to each built-in), and didn't have "slow CGI overhead" or "FastCGI complexity".
Python was waaaay easier to read/write/maintain, and was a serious alternative (except for trickier process-control integration, you couldn't just "$XYZ = `ls -al`" like you could in perl).
...and then "PERL6 will be gloriously filled with rainbows, butterflies, will be backwards incompatible, and will be released Any Day Now(tm)" sucked alll the oxygen out of a developer investing in perl.
By the time nodejs became another contender for server-side languages, there was no place for PERL as it's effectively become kindof a COBOL for unix systems. Don't touch it if you can avoid it, and it requires expensive, difficult-to-find specialists to maintain it if you need to.
PHP was jokingly expanded to 'People hate Perl' back in the day
> Also, even if Perl 6 had never happened the way it did and instead we'd just had smaller evolutions of the language in major versions, I think usage would still have shrunk over time.
Maybe. I mean the whole point of 6 was to modernize perl.
Perl needed efforts like 6 to happen, but it needed them delivered in smaller chunks over the years rather than as a big decade long "And now 6 is here".
Java learned this lesson after Java 8 and 9 which took multi-year effort to deliver 1 or 2 big changes to the language and the JVM. Now Java has multiple efforts in flight which have trickled in over the years (tickling me as a dev). Every 6 month release is a little better which makes the multi-year efforts seem all that much more worth it when they land.
> A lot of people just dislike Perl's weird syntax and behavior.
As much as I liked Perl back in the day, it did sometimes earn its reputation as a write-only language!
My impression was experienced Perl programmers took pride in making the smallest code possible, all in one line.
At my company they really locked in the project being dead if the original contributors left.
Perl propped up regex (JavaScript regex is based off of it), so I get the impression Perl practitioners tried to make all the code regex-y as possible as a cultural thing.
There was a regular feature in the perl community for 'golf' or 'crazy one liners' but almost no one used that shit in any actual code that left their user directory.
I remember the Perl art competitions, where you would write Perl code that would run and actually do something, and would be ASCII art at the same time. Obviously, lots of camels ;-)
> Perl programmers took pride in making the smallest code possible, all in one line
And this became a joke and meme.
Code golf is fun as a challenge, but it's obviously hell to find in a script someone else wrote that you're supposed to maintain.
Not to mention that trying to understand existing Perl by asking the community 'what does this do' or 'how does this work' often (in my experience) resulted in 'RTFM' or 'man perldoc' rather than someone taking any time to actually answer the question, whereas other communities were more welcoming and helpful to each other. That made it difficult to learn Perl through other people's code compared to other languages.
I had the complete opposite experience. Perlmonks and irc were amazing resources for a budding developer.
agreed
I think that depended on where you were looking and how you were asking.
My main source of support back when I did much Perl (late 90s, early 00s) was usenet, and while some groups were very snubby and elitist others were very helpful and encouraging for a young budding programmer.
This matches my experience.
I started programming in the late 90s using Perl as my first "real" language. When I first saw some Python code (2.3 if memory serves), I found it much easier to understand. Not necessarily easier to write, but diving into a Python codebase 6 months later was a lot easier than doing the same than with Perl. Purely subjective, but I was far from the only one, even if quite a few people at the time preferred Perl.
Later, when the Web really took off, running PHP 4 was much easier to get going than either Python or Perl, so a lot of us went with that.
And yeah afterwards JS with node.js in particular. The millions pumped into it by Google certainly helped.
There was also a time a bit later with Ruby getting really popular. Not just for new projects, I heard of some codebases migrating from Perl to Ruby, when the writing was on the wall for Perl 5.
Go, I think when it became popular not many people were still using Perl. Also not really something you would use to bang out a quick script with. Probably more of a competitor to Java.
As for me, back to Python as my bread and butter. Probably haven't touched Perl in 20 years at this point. Looks like gibberish to me now...
All good points. There was a solid talk on modern web dev with Perl at the Carolina Code Conference last year.
Created some interest in several people who talked to me about experimenting with it for a while afterwards.
https://youtu.be/ommhbiRx-vI?si=qwkdU1Wo7uVBVse9
True. Adding to these. Perl6/Raku suffered from the second system effect. Described in the Mythical Man Month. Larry and company were over confident with their previous success.
Perl was pretty much first in the wave of interpreted languages from the late 80ies and 90ies. It set the bar on what to expect from such ecosystems.
But being the first meant it got some oddities and the abstractions are not quite right imho.
A bit too Shell-esque, specially for arguments passing and the memory abstractions are a bit too leaky regarding memory management (reference management fills too C-esque for an interpreted language, and the whole $ % @ & dance is really confusing for an occasional and bad Perl dev like me). The "10 ways to do it" also hurts it. It lead to a lack of consistency & almost per developer coding coding styles. The meme was Perl is a "write only language".
But I would still be grateful of what it brought and how influential it was (I jock from time to time how Ruby is kind of the "true" Perl 6, it even has flip flops!).
In truth, these days, I feel the whole "interpreted languages" class is on the decline, at least on the server. There are a lot of really great native languages that have come up within the last few years, enabled in large part by LLVM. And this trend doesn't seem over yet.
Languages like Rust, Swift, Go, Zig or Odin are making the value proposition of interpreted languages (lower perf but faster iterations) less compelling by being convenient enough while retaining performance. In short, we can now "have the cake and eat it too".
But the millions of lines in production are also not going awywhere anytime soon. I bet even Perl will still be around somewhere (distro tooling, glue scripts, build infra, etc...) when I retire.
Anyway, thank you Perl, thank you Larry Wall, love your quotes.
https://en.wikiquote.org/wiki/Larry_Wall
> And Go came along and provided an aggressively mediocre but very usable
See, that's one of the things lots of people who enjoy Perl and/or Ruby in the comments around in this thread don't quite grasp: some languages require programmers possessing a somewhat special state of mind to read and write productively, and some languages allow pretty much every mediocre programmer to read and write, and still produce a manageable program.
The other thing is the information density. In my experience, most people after graduating high school have experience with reading mainstream fiction and school textbooks, and those things you can half-skim/half-read and still get out most of the meaning. Then those people hit the college-/university-level textbooks and screech and crash because those books, you have to read them sentence by sentence; not everyone can get get used to it (or even realize they have to do that in the first place). And similar observations hold for programming languages: Perl and APL are just way too dense compared to Go and Python; if you're used to reading code line-by-line (skimming over half of them), then it's really bloody annoying to switch to reading sigil-by-sigil (as for writing, well, we all know that typing speed was never really a bottleneck for programmers).
My main complaints about Go are not that it needs more obscure syntax. The biggest problem with Go is basically that the core of the language's syntax is special, and only accessible to the compiler. This goes hand in hand with the language not offering generics out of the gate. This means that things like slices, maps, channels, etc. are all special. You cannot implement anything similar that uses the same syntax (even now that generics exist).
This lack of flexibility means that it's impossible to experiment with replacements for built-ins, and the lack of generics out of the gate meant so many things were simply impossible (like useful iterators).
Compare this to Rust, where almost everything like this is just a trait. If you want to offer a map replacement, you just implement the Index and IndexMut traits.
Overall, I don't think Perl is the best language design. It has some interesting ideas. Go is _also_ not the best language design. Is Rust the _best_? No, but it's better than both Perl and Go, IMO.
> special
Many of us see that as an important feature, and a smaller set of people aren't too happy with the generics introduction for example. Or the recent iterators stuff they have added.
It makes codebases touched by a lot of people an absolute breeze to understand. There's no clever generic data structure/soup of traits/clever conditional types I have to understand from scratch. Everything is the same old boring maps and slices and for loops, nested sometimes. And functions mostly always return 2 values. There is no map/filter/anything. The name of function usually betrays the types. "getUserPreferencesBatch" is most likely a `func(userIDs []UserID) map[UserID]Preferences, error`. There's <1% chance it is anything else. People also tend to avoid relatively complicated datastructures like trees unless they are really really necessary. So you get boring, completely predictable, 70% optimal code.
Even when discussing implementation, people think in simple terms which leads to really simple implementations in the end across all team members. It basically makes drumming KISS into everyone really easy.
Now some people go all clean code or make functional wrappers and such, and that destroys all that's good in go.
But I don't want to read your cute custom hashmap code. Go really shot for the stars with its primary design goal of uniformity. The hashmap you're using is the same one I'm using, is the same one any random Go repo on Github I open uses. The value of this is immense—I instantly feel right at home, I know the exact semantics you're using—we're speaking the same language.
To wit, I would argue that Go didn't go far enough in restricting the user and certainly did not pick the right features to include. I don't think it's clear at all that had go shipped with sum types—enabling better error handling—and iterators, more built in generic data structures, and higher level abstractions around its concurrency, but no generics at all, that we wouldn't end up with a far better language. A more restricted one, with even less room for anything custom, but a better one.
Agreed. It's interesting that the design decisions that make Perl and Go problematic are pretty much at opposites. Both are extremists, in a way.
>It confused CTO/VP Eng types
I wouldn't call making the right decision confused. It clarified and justified their desire not to use Perl. Only a confused CTO/VP Eng type would choose to use Perl in spite of all its entrenched disadvantages and much better more popular alternatives.
I was just saying that they were confused about what was going on with Perl because if the Perl 6 effort. I don't think that they were confused or wrong in their decision making.
Python and Ruby killed Perl.
Before Perl, there was no scripting language that could do systems tasks except maybe shell and tcl, but that's shell is an extremely unpleasant programming experience and the performance is horrid, and tcl's string-based nature is just too weird.
Perl gives you something more like a real programming language and can do shell-like tasks and systems tasks very nicely. Compared to what came before, it is amazing.
But then Ruby and Python came along and checked the "real programming language" box even more firmly than Perl while retaining the shell/systems angle. Ruby and Python were better than Perl along exactly the same axis as the one on which Perl was better than Tcl and shell.
IMHO Python killed both Perl and Ruby. While Ruby is more alive than Perl it's nowhere near as popular as Python.
I like Perl and used it professionally for year and vaguely remember probably around 2010x relatively massive Python evangelism (lots of articles, conferences, lots of messages from Python adepts on forums e.t.c). One of talking points (no longer needed nowadays) was that Python is backed (sponsored) by Google so Python will be successful and you should not worry about it's future and also if you will choose Python you will be successful (as Google is).
I think Ruby has declined because Rails was its selling point, but Rails was optimized for the world of HTML templates. Once you're writing JavaScript-heavy frontends and mobile apps, Rails isn't giving you much that you can't get from Python or server-side JS.
A few people started using Ruby for command line tools[1] but the community was very focuses around rails. Also Ruby isn't usually part of the standard OS install. So Ruby stayed stuck in it's Rails niche.
[1] Some listed here: https://en.wikipedia.org/wiki/List_of_Ruby_software_and_tool... https://en.wikipedia.org/wiki/Category:Free_software_program...
I think it's standard on macOS.
>>While Ruby is more alive than Perl it's nowhere near as popular as Python.
Haven't seen anybody start a Ruby project in more than a decade. Whereas Perl still has held its fort i.e Automation/Glue work on Unix systems.
> Python is backed by Google
For me, this is why python took off. People wanted that lucrative job or receive the reflected glory of a winner, so y'gotta learn python. The rest is just post-hoc justification for why you made that choice passed on as "this language is better because of blah..."
A lot of the justifications don't stack up against serious scrutiny, but are accepted as gospel.
> IMHO Python killed both Perl and Ruby.
I think you're right.
(I say that as someone who still very much loves to program in Ruby.)
> and tcl's string-based nature is just too weird.
TCL had the ability dynamically load and call into .so’s which was really powerful. Those who knew, knew.
Yeah tcl is awesome.
It's both awesome and weird.
Some people use it effectively to this day. Most either have no idea about it, or know about it but can't get into the mindset (like me).
Common Lisp for the masses
> "Perl gives you something more like a real programming language ..."
It is a real general-purpose programming language, not a "scripting" language. Did you ever have a look at it?
In previous life, worked on large object-oriented Perl. There was a difference between good Perl and the Perl in messy scripts. Good Perl was nice to work in but required discipline to keep organized.
I wonder if there was an earlier point of Perl's demise. Perl 5 came out with flexible object-oriented features, but it took years for packages like Moose to come out and make it nice and usable.
I always thought one of the best and worst things about Perl was the fact that you could build something like Moose with it.
But the bad side was that by the time someone was clever enough to invent Moose, all sorts of other bespoke object systems had been invented and used in the meantime, and your CPAN dependencies used every single one of them.
I’ve shipped Perl code so yeah, I have
Good luck getting any two people to agree on a sharp line between programming language and scripting language. Perl seems to swap sides depending on the year people are arguing about it.
In my experience those can't discern what's what are usually the ones who mainly did a bit of dabbling in either.
Assuming you've done more than dabbling, what's specifically the difference to you then?
For many people especially old timer sysadmins, anything interpreted at runtime is a script.
TBH, prior to perl6, perl was such a horrid inconsistent mess, it reeked of shell.
BASIC and Pascal are real general-purpose programming languages as well, but I don't know anyone who uses them for anything serious.
Entire enterprises ran/still run on Business BASIC and Delphi code. Billion-dollar fortunes have been made on such code. Those languages are used for serious things all the time.
* for new code
That's a difference without a distinction
Python killed Perl.
By the time Perl 6 was around, Perl's lunch was already eaten by Python. Only a few table scraps left. Perl 6 would have had to be a better Perl 5 and a better Python 2 to win.
Python came with better batteries and better syntax. It allowed producing code you could read and understand a week later. Perl I found was a write-only language for me. I went back looking at my old Perl code and I couldn't decipher it without some effort.
And Python became popular not just because it was a better Perl, but it attracted folks who used Java and C++. CPU speeds were getting fast enough that you could actually do file and network IO at acceptable speeds without all the `public static void main(String[] args)` and `System.out.println(...)` boilerplate, but still had all the object oriented bits like inheritance and composition with which you could go crazy with if you wanted.
Personal anecdote in support: my first job out of college was at a data-analysis company, where my task was usually to write one-off scripts to extract data from various data sources and massage it into the format the analysts wanted for their spreadsheets. I wrote most of those scripts in Perl at first, with the odd Bash script here and there. Then one of my coworkers said "Hey, if you like Perl, you'll love Python". I learned Python (2.1 was the most recent version at the time, which tells you how old this story is) and almost immediately switched over. All my new one-off data-extraction scripts from then on were written in Python (though still with the odd Bash script here and there).
When I was doing undergrad CS in 2006, we had a choice between Perl and Python for our scripting assignments. As far as I know, no one chose Perl. It's comparatively a huge pain to get ramped up on, and the promised payoff is that you get all these implicitly stateful sigils that let you write contest-winning one-liners. But by the early 2000's, the culture was getting up to speed on obvious-in-retrospect principles like "avoid global variables" and "you should give your variables names that someone else can understand", and even as students we could all see that Perl wasn't going to be the future.
I chose Perl first. At that time around early 2000s it was the more popular. I liked how my scripts were short and compact but then I I had noticed that I couldn't understand what I did week or so later. The "write-only language" joke was kind of true for me. Then remember finding Python and rewriting all my script in Python and have been using it ever since.
> Perl 6 would have had to be a better Perl 5 and a better Python 2 to win.
Don't sell perl 6 short. I am using perl 6 for significant projects now (after a career of perl 5) - and it's fundamentally different. I describe it as perl to the power of perl.
For me, expressiveness is fundamental. And perl 6 gives me that.
Perl 6 is simply suffering from python being everywhere. And perl 5 was always easy to lampoon as "line noise". It's a stupid quip, but it leaves a mark on new programmers. You don't even need to read the course and you can already have an opinion. Stupid kills? And then perl 6 doubled down on that anyway. Then I doubled down on that ALSO and I get to use (carefully chosen) unicode symbols in my line noise :-) So there.
> For me, expressiveness is fundamental. And perl 6 gives me that.
I saw Larry Wall at one of the conferences. He talked a about Perl 6 how it was progressing and such (it was before it was renamed) and year, expressiveness what stuck out. It certainly has lots of nice features, too. But at least for me, I realized with Perl 5 I wasn't smart enough for it. I would be lured by the clever short expressions and then sometimes later look back and had no idea what I wrote.
Larry is a great person, btw. During lunch at the conference sat at his table and he was very approachable and warm. I don't remember what we talked about exactly just that it I liked how down to earth and nice he was.
> But at least for me, I realized with Perl 5 I wasn't smart enough for it.
I feel like you but I love it: I am not limited by the language. Not by perl 5 and not by perl 6: When I am willing, I can dig deeper and find more to work with. When I am willing I can try and follow presentations or books by Damian Conway, Mark Jason Dominus, etc and I can get new ideas and inspiration. I can always learn more about this fundamental tool that's at the center of what I build. The tool challenges me in a good way. It does not slow me down. It does not limit me. If anything in there is going to limit me, it's going to be my own brain.
And perl does that without tripping me. Because in perl, the intuitive way is one that's not likely to hurt you. While if you know better, you can work with the more elaborate, deeper features.
I hate it when I have to use a language that constantly limits me. It has happened. I am not always free to choose the programming language or platform. For some, it's so frustrating that I charge more. And it's still frustrating.
Since you're actively using it - how's performance in Perl 6? Are the rumors that it's slower true or exaggerated?
I have exactly zero functions that are written in both. So comparison is just intuitive:
My current projects make extensive use of numerical functions AND of regexes and grammars. Both used extensively. I am very satisfied with the performance on both aspects. It does the job. And there is no question that for the regexes and grammars, what I have goes FAR beyond what I ever dared to run in perl 5. Performance is good, including on this stuff that I feel would have been pushing perl 5.
Still, I write for expressiveness. It matters to me how fast I can write. And I am NOT satisfied with "searching through the doc". That's the main sore point for me. The doc is very good but online-first and local... eventually. So I am stuck using an online search function... which constantly falls short.
I would bet against this hypothesis.
Perl exploded because it was the easiest, richest ecosystem available to plug into CGI and the web.
PHP & Ruby & Python then collectively covered the same waterfront whether you wanted “easy” or “fun” or “simple”.
And I would propose that PHP attracting the developer cohort who wanted “easy” and Ruby/Rails attracting the developer cohort who wanted “fun” were each individually more damaging to the Perl ecosystem than Python.
Agreed. In grad school, I used Perl to script running my benchmarks, post-process my data and generate pretty graphs for papers. It was all Perl 5 and gnuplot. Once I saw someone do the same thing with Python and matplotlib, I never looked back. I later actually started using Python professionally, as I believe lots of other people had similar epiphanies. And not just from Perl, but from different languages and domains.
I think the article's author is implicitly not considering that people who were around when Perl was popular, who were perfectly capable of "understanding" it, actively decided against it.
PHP also contributed. Perl CGIs were a very popular way to build early web apps.
PHP contributed hugely for me. I was writing a lot of Perl for web apps from about 1996 to 1999, when PHP really took hold and was an improvement in almost every way, right down to including PCRE regex functions. Perl felt clumsy compared to PHP, especially for MySQL and other relational DB stuff. PHP was built for the web.
> By the time Perl 6 was around...
Just my opinion, but this says more about perl 6's insane development schedule than python's advantages.
To me Perl was just Weird, to no particular end. Not the kind of mind expanding Haskell/Prolog/Lisp weirdness that opens up new possibilities. It just does roughly the same things as every other language, but everything is done slightly differently due to evolving out of the primordial soup of bourne shell and AWK filtered through Larry Wall's brain.
Perl and Python were similarly powerful and useful languages, but I could learn and start producing useful code in Python after reading an hour long tutorial. Perl took an order of magnitude longer, and remained more awkward to use just due to the Weirdness. There was a momentum building in the early 2000s toward competitors like Python and Ruby that were seen as less crufty and more modern.
Perl's developers seemed to agree, since they cooked up their own competitor to Perl, an entirely different language confusingly called Perl 6. The coexistence of Perl 5 and 6 made the Python 3 transition look like a cakewalk -- at least it would have save for Perl 6's almost entire failure to exist for over a decade after its inception. It produced lots of constantly churning specs and blog posts about register based virtual machines with native support for continuations or whatever, but no implementation of a language that anyone felt comfortable using for any real development. Meanwhile people kept using the ossifying Perl 5 for existing applications, and gradually transitioning away as they were replaced.
Also PHP overtook it for the "just FTP a script to $5 shared hosting and make a webapp" use case.
I agree, and the blame for its weirdness can be laid directly at Larry Wall's feet, because Wall wanted a language that allowed for cleverness, suprise, and ingenuity. He was never happier than when someone would come up with a completely new way to do something. For Wall, programming was less about coding an outcome, than it was about speaking a particular language (and ideally, writing poetry in it). And it was very successful in this way, and fit reasonably well with the high-knowledge users/environment of unix in the 90s.
It's just that Wall's vision was incompatible with general purpose languages used widely by a wide range of knowledge and skill amongst its users, and as unix/linux opened up to that wider range, better general purpose alternatives were chosen. Having to learn to be a poet to be a good coder was too high a barrier.
> Wall wanted a language that allowed for cleverness, suprise, and ingenuity. [...] Having to learn to be a poet to be a good coder was too high a barrier.
To me this just sounds, umm, pathologically eclectic.
But I bet you could really list some rubbish with it…
Now extrapolate to "let's do a Perl 6 that allows us to do all the things I couldn't work into Perl 5" and a lot more history makes sense.
Larry Wall is a linguist.
Perl is most human-like programming language, which is what makes it great, but also what makes it unreliable for large scale programming.
> Perl is most human-like programming language
This claim always seemed bizarre to me. What kind of drugs do you think a layman would think you were on if you showed them a typical Perl program and asserted how "human-like" it was? Even if you tried to follow-up and explain it: "No, no, see this bit means open whatever file stream is specified in the command line, as long as it starts with a letter between 'A' and 'F' that can be either upper or lower case, and is followed after any random characters by at least 3 digits in a row. Then this next character means.... See? It's just like I'm describing it to you!"
I remember the "Aha" moment on the face of a python-flavoured data scientist when I showed her my Perl scripts for managing LDAP groups.
One look at the class files (written in Moose) and she was stunned that she could immediately understand it, having never written Perl before.
Perl "died" through a 1,2,3 knockout of
1. failing to have a coherent path to Perl 6
2. Ruby (on Rails) taking over the workhorse task of serving up dynamic content that Perl had owned before then
3. Python completely dominating the utilitarian scripting/programming world in nearly every niche
Why did this happen? I was a work-a-day developer working in Perl v5 when this transition occurred and from my perspective and recollection v6's meandering development cycle -- which didn't really address the issues of the broader Perl community was the primary choice. Perl 6 was developed in a way that didn't address the broad concerns of the Perl community, and expected people to make a wholesale switch to what was effectively an entirely new language anyways. It forced people to go out looking and what they found were either stronger solutions to specific domains (Ruby on Rails) or a nicer language than what was being proposed (Python).
Where Python really excelled at the time was that it looked and worked very much like the pseudocode that was going around at the time, and had an opinion about how you should write your code. Perl is wonderful to write in, but in many ways is too expressive and permissive and it resulted in an ungodly mess that could be hard to maintain. Perl 6 simply leaned into that problem rather than encouraging a cleaner approach.
I never liked Python much, but damn if I couldn't argue that I was much more productive with it than Perl in the end. Which was weird because when I was really hacking in Perl I could write code almost as fast as I could think giving a kind of illusion of productivity. But Python was easier to integrate into a coherent team development structure and actual productivity is more important than feels.
I miss working in Perl. But I knew it was really finally dead when I was giving tutorial classes to new bioinformaticists who were being given old Perl codebases to update and they were getting through school without learning the language.
I would say PHP instead of Ruby was the big hit on Perl for web. It sat nicely in Apache and made replacing old cgi-bin much easier. It also had the philosophy and syntax heavily inspired by Perl
Python was indeed the scripting replacement. I would say it won because of its philosophy on simplicity and explicitness. Perl v5 suffered heavily in complex projects because the language itself was too complex and often cryptic
I think you're right about the significance of PHP.
PHP kicked Perl's butt in the shared web-hosting environment.
You could do amazing stuff with mod_perl, but it was not possible to run a shared host with mod_perl without exposing every customer to every other customer's code. You could still do cool stuff with vanilla CGIs. Perl was practically synonymous with CGI back in the day. Once you grew past what a simple CGI would handle, it suddenly got a lot harder and a lot more expensive.
Meanwhile, PHP had simple Perl-like syntax and ran nicely in shared hosting. Better yet, you didn't have to choose from one of the 400 different Perl templating systems. No need to choose between TemplateToolkit, HTML::Mason, or Embperl. You just used the standard, built in templating.
PHP won because it was worse, you didn't have the power or choice Perl provided, but it was more than good enough and it was cheaper to grow with.
On Perl vs Python: - Perl was weird and proud of it, it promised creative power and flexibility - Python promised regularity and clear rules
- Perl tried to make hard things easy - Python tried to make routine things routine
- Perl had weird primitives that let you build whatever magical OO nonsense you wanted. - Python supported writing glorified struct OO that was fashionable at the time
- Perl was difficult to integrate with C libraries - Pyton integrated much more easily with C libraries
That being said, I like Perl much more than Python. Using Perl still feels magical, even if some of the syntax is odd. Using Python feels like I have my shoes on the wrong feet.
There's more than one thing that "killed perl" (I still use it almost every day.)
But I think the main thing that made it long term non competitive were a series of bad design choices all the way back to perl 4 or even 1.
Namely:
- the need for sigils
- weird sigil rules where the 0 element of @x is $x[0] not @x[0]
- auto flattening, ex. (@a, @b), and hence the need for manual reference management, as in (\@a, [1,2,3])
- lack of a native object system, and widespread repurposing of hashrefs as objects, with awkward field syntax $x->{foo}
- awkward function argument syntax: my ($x, $y) = @_;
These things add up, and both JS and python showed that all those can be done much more smoothly.
Another thing that counted at the time, is that PHP came out with a slightly worse language, but a super beginner-friendly approach to html templating and request lifecycle: you can just mix php and html in the same file, and the entire runtime environment is nuked at each request. The result was that php replaced perl for an entire generation of web devs in the early 2000s.
Hm, if I understand this correctly
then you might be interested to learn about feature 'signatures': Not sure when it was added, but when I write the usual glue code, I love to use it these days.I guess "weird" triggered me a bit, heh. I know it's subjective.
haha even your explanation looks 'write only'
Sigils are essentially type tags. That's it.
Array x === @x
Int x[0] === $x[0]
To get Perl to work with apache (the most used web server for a time), there were two options: the not-so-complicated cgi script which gets executed from scratch on every request, then there was mod_perl which required a lot of tinkering with apache configurations and writing your code in a different way.
Even with those two options, you can't just write some code in a page and execute it without some sort of itermediate code.
Thats why php became so popular, perl coders could pick it up in a day ($ and all) and all you have to do is write .php files to a server - with the bonus that you have a rudimentary templating system built-in to php.
There really isn't much more to it than that.
I vividly remember the first time a friend showed me PHP in the late 90s. You're saying I can just write a script that generates HTML and throw it in /foo/index.php and that's the whole thing?
It's wild that right up until Rails got popular, we were writing code that served billions of requests off of homebrewed MVC-ish PHP frankenframeworks.
> mod_perl which required a lot of tinkering [...]
Here we used mod_perl all over the place and it was glorious. It did take understanding how to use it - well, yes - same as the rest of perl (or apache for that matters). But it was so well integrated! I still miss it.
"Picking it up in one day" is not a criteria for professional deployements.
> Here we used mod_perl all over the place and it was glorious. It did take understanding how to use it - well, yes - same as the rest of perl (or apache for that matters). But it was so well integrated! I still miss it.
See https://news.ycombinator.com/item?id=45989369
Most people, including small businesses, used shared hosting providers back then, and none of them supported mod_perl, while most of them eventually did support mod_php. That's why PHP came to completely dominate the market for self-hosted (or hostable) web applications, like phpBB, Drupal, and WP--writing those in anything other than PHP after mod_php became available (but before AWS) made no sense. PHP was at least as ubiquitously supported as Perl, and through mod_php (avoiding CGI's overhead), much faster.
> none of them supported mod_perl
Once mod_perl existed (it was late, after lots of CGI perl) - I feel that my clients and I never had significant difficulty in finding providers. PHP was all over the place - it felt - more because there was demand. But there was enough demand for mod_perl that it was always there when we wanted it. We never had to really hunt for a hosting vendor.
> I feel that my clients and I never had significant difficulty in finding providers
Yes, for professional uses. But we lost the next generation of devs. You could put PHP on any shared webspace and people started messing with it and from that messing, the next generation of open source PHP programmers came.
mod_perl hosting was much more expensive.
If you wanted to throw up a personal project using mod_perl you pretty much had to pay for a hosted box. At least once people realized how insecure it was to run shared code on a mod_perl host.
You could find hosts but it was comparatively expensive.
Plus it was a huge pain in the neck to do things like install the modules you needed on a shared host.
This was a huge barrier to entry and it made things unreasonably difficult. Meanwhile PHP was very low friction. And at the time, so many new people were teaching themselves web development to scratch itches and solve problems that these barriers were a big deal.
Which sucks, because mod_perl was amazing, beautiful tech.
> At least once people realized how insecure it was to run shared code on a mod_perl host.
People realized this immediately, given how much mod_perl exposed Apache's guts to script writers (so they could write modules in Perl--a feature few asked for, and fewer used) and how tightly coupled the two were, so much that calling Perl's humble 'exit' built-in became a notorious footgun (until, IIRC 5.6), terminating the underlying Apache process itself.
This is why I preferred Mike Migurski’s nickname for PHP: Apachescript; easy to integrate to the web server and next fastest thing to C for Apache.
I had to do a double take when I learned that modern cloud services still support PHP.
Mentally, I put it in the same bucket as legacy ASP, which is looooong dead.
My hypothesis is that as the volume of Perl grew, it became more and more apparent that it wasn't a good idea to write new projects in Perl:
- Perl's fascination with punctuation makes it hard to google for stuff, since search engines strip punctuation. In an era of RTFM and grep, maybe this is okay, but puts the language at a substantial disadvantage vs languages that use more prose than punctuation
- The distinction between scalar vs array context is subtle and feels somewhat pointless if you learned a language like C or JavaScript first. C has no overloads but manages to work fine, and other scripting languages like JS or Python let you branch on the runtime type of variables explicitly. Why bother with array context?
- Similarly, people got used to having named function arguments in their function signatures. Maybe in an era where most code was either compiled (and had named function args), or was stringly-typed and scripting like Bash, Perl feels like more of the same. But once we started getting decent scripting languages that had named function args, it became a real pain to repeat basic stuff like "assign parameter 1 to variable $name, assign parameter 2 to variable $age" in every function. I wish shells would bite the bullet and figure out a way to adopt them.
Overall, our industry is moving towards larger scale and complexity, and at larger scales, reading and maintaining code is more important than writing code. Perl's language design choices are all balanced for 1-10 unix wizard authors having fun writing small scale scripts. Compare it to Java, the Anti-Perl: today scripting languages like Python, JavaScript are getting closer to Java or ML with compile-time type checkers and sophisticated type systems. Few new or existing languages are getting similar to Perl.
I don't think Perl 6 had anything to do with it. I wrote a lot of Perl5 in college, and didn't particularly want to write any more Perl5, or adopt Perl6.
Already in the very early millennium, jokes like “Perl is an explosion in an ASCII factory” were going around the computer-nerd community, while several publishers were putting out affordable and fun and engaging books to learn Python. No surprise that Perl quickly declined in popularity for scripting. It has been amusing to watch the continual waves of reawakened interest in awk, while Perl seems to remain perennially marginalized now.
The value proposition for AWK is very different from Perl. AWK is a tiny language that can be learned quickly, and it's ubiquitous: a hard requirement for even the most bare-bones POSIX environment. AWK is on your machine already; Perl may not be. If you have to install Perl, you could just as easily install any one of hundreds of alternative scripting languages.
AWK scripts don't have any kind of dependency management features, so they naturally lend themselves toward being freestanding and self-contained. Perl, on the other hand, has a massive package ecosystem with transitive dependencies and widely varied quality and design aesthetic, amplified by the baroque design of the language. AWK is as close as a language can be to immune to dependency hell.
When Perl was new, perhaps many people saw it as "a better AWK", but I suspect most of the newcomers to AWK today don't see it in relation to Perl at all.
For me, Awk is this awesome tool for quick and dirty 1-3 line scripts to transform textual information. I hardly use it, but when I do, it serves its purpose well. It's also relatively easy to read and understand.
I remember learning most of Awk from a long, single web page that appeared to come from one of the official authors.
Perl died because the other languages are better. IMO, Perl was a quick solution to a need; but it has since been eclipsed by modern languages.
I was in college 1999-2003, I did PHP in an internship, and then later did some Perl in one of my classes.
Perl (in my college class) was so incomprehensible that I decided that I would avoid it. I've never applied to a job that uses Perl, and never responded to a recruiter that was looking for a Perl engineer. I've never had to use it at work, and fortunately I've never worked with anyone who wanted to use it.
I think it's best to think of Perl as a transition technology.
It's been discussed before, but Python just seemed more straightforward to a lot of people. It had a built-in object oriented model as well when that was the rage instead of the weak default one and dozen modules on CPAN to do object oriented programming. There was generally one way to do something and that was easier to learn than TIMTOWTDI.
Yes, the answer is Python, Python, Python.
There's a reason the Zen of Python includes this:
"There should be one-- and preferably only one --obvious way to do it."
It also came with batteries included, which really lowered the learning curve.
Perl was well known for being a pain to read months after you wrote it. Most Python code in those days was readable by people who did not even know Python.
When I started my job in 2010, I took a class at work on Perl. I had done some Perl years before and had grown sick of it, but I thought I was just doing it "wrong" so I thought the course would tell me how to code in Perl "properly".
Nope - I'd been doing it "right" all along. I just hated the language. At the end of the course, I told the instructor (a graybeard) that he should just use Python, and that one day I'd teach the Python course and he should attend. He scoffed at the notion: "Languages will come and go, but Perl will always prevail!"
I never did teach that course, but I bumped into him about 7 years later. He had completely (and willingly) abandoned Perl for Python, and was a big Python advocate.
if only python stuck to any of those ideals
Python has grown some warts, but I can still read code I wrote 20 years ago.
People who don't know Python will have a harder time reading modern Python, though.
One of Python’s killer features is how easy it is to find a Python library wrapping some native code library written in C or Fortran. Those used to be notoriously difficult to write for Perl.
I was writing a comment asking if it was really easier. Then I took a look at Cython. Yes, this looks easier than Perl's XS, which I have some experience with! There are ways to do something similar in Perl these days, notably https://metacpan.org/pod/FFI::Platypus. But these are relatively new (starting in the 2010s) compared to the history of Perl, and Cython goes back to the early 2000s.
Somewhere in the continuum from SWIG through XS and on to Platypus there are also the Inline modules these days. They allow one to put inline sections of other languages into Perl code the way many language tools used to allow one to inline assembly into C or Pascal code.
There are some of these modules for other languages than those listed here, a lot of them as high level as Perl (including Raku and even another Perl system for some reason).
https://metacpan.org/dist/Inline-C/view/lib/Inline/C.pod
https://metacpan.org/dist/Inline-ASM/view/ASM.pod
https://metacpan.org/dist/Inline-CPP/view/lib/Inline/CPP.pod
https://metacpan.org/dist/Inline-CPR/view/CPR.pod
https://metacpan.org/pod/Inline::Lua
https://metacpan.org/dist/Inline-Java/view/lib/Inline/Java.p...
https://metacpan.org/pod/Inline::Guile
https://metacpan.org/dist/Inline-SLang/view/SLang.pod
There are even tools to convert from Inline to XS for C and C++.
https://metacpan.org/dist/InlineX-CPP2XS/view/CPP2XS-Cookboo...
https://metacpan.org/pod/InlineX::XS
True. For whatever reason, these never displaced XS. For wrapping C libraries in particular, it's not clear to me how much Inline::C helps with this. You're still stuck using a lot of Perl C API calls, AFAICT, which I think is the biggest challenge of using XS (I still have nightmares from trying to figure out where and when to add `sv2mortal` in my XS code).
I haven’t done nearly as much of this as you.
One or two calls into a library with a simple C interface isn’t that bad with Inline. You just use Inline to handle the Perl to C to Perl part, and actually do the interfacing in the inline C. It’s a lot more mess if you’re doing complex things and bringing complex data structures back to Perl, or having Perl make a lot of intermediate decisions and doing a lot of round trips. So if you use Perl to get the data ready to pass in, pass it in, do all the work in C that you need the library for, then pass the results back to Perl once it’s not terrible.
I’ve tried not to get into XS, so I couldn’t really compare.
Using Inline::C with your own C code in places where Perl is too much overhead is certainly easier than wrapping a complex existing library with a lot of interactions across the boundary.
FFI::Platypus or something like it really is the way of the future though for existing C calling convention libraries in other languages.
TIMTOWTDI broke down with trying to do OOP in Perl. You could either bless a hash, or use a meta-object framework (moose?). You could end up with hierarchies of different types of objects with their own behavior.
Back in the day it was Perl or PHP on the web
I was a Perl programmer, and I looked down my nose at PHP. Silly me, then and now
Why did PHP, an objectively a worse language, win?
Rasmus Lerdorf said in a quote I can no longer find, it was modperl vs. modphp for Apache.
Modperl was, typically for Perl, very comprehensive and allowed access to all the Apache processing hooks
Modphp was, typically for PHP, just enough to speed up rendering so only allowed access to the barest minimal set of hooks
Modperl, so much better (I can hear myself say 30 years ago)
But at the time most websites, by count not by traffic, ran on shared hosts where the system administrator gave you access to software. If they installed mosdperl you would be able to intercept, read, and change traffic for all websites hosted on that machine
Modphp, not so.
So PHP was widely available to the pioneers in the day, people scratching together a little web hosting business and growing . Perl was not
Not enough on its own to kill Perl, but an important nail in its coffin
I learned and used Perl professionally from around 2005-2015 and experienced first-hand the ossification, fear of change, and lack of innovation in Perl 5 development. It seems all the talent and effort started being wasted on making Perl 6 the bestest, most elegant, most useful programming language in the world. Just seeing the neglect of Perl 5 kept me from ever considering Perl 6 and motivated me to move to other languages.
I started learn Perl 5 right before 6 was announced. When I saw what was happening with Perl 6, I decided just to stick with sh, awk and friends.
IIRC, The Perl 6 development thing went on for a very long time and got nothing but bad press. That took the wind out of my sails.
My experience of working with Perl as a primary language from late 90s to today: Perl was dead long before Perl 6/Raku was a real thing. By the time that happened it had already lost massive ground to PHP, Python, Java, etc.
PHP had replaced CGI as the easiest way to get code on a webserver, Python and Java were easier to read and understand, easier to structure large systems with, and generally easier to use. Ruby came along and MVC frameworks became the thing for complex web platforms.
Meanwhile Perl was sorta keeping up, the "Modern Perl" movement helped dispel myths about "write only" code, things like Moose, DBIC, Catalyst, Mojolicious, etc meant you could write pretty modern stuff with it. But the community was smaller, fractured by Perl 6 and dominated by some ahem divisive characters which made it intimidating for newcomers, and it just slowly died from there.
By the time Stack Overflow came along it was easy to see that other languages had vibrant communities surrounding them and for me it never really recovered.
About a dozen years ago, I noticed that the young all seemed to know Python, and did not seem to know Perl. Given that they would be maintaining such code as I wrote and was worth keeping around, I moved to writing in Python. Now when I write Perl, I do silly things like forget semicolons.
Perl can be very well written. I deeply regret not encountering Perl Best Practices when it came out.
I think it is due to the fact that Perl has some confusing bits like those variable prefixes ($@%), the lack of function arguments (I know that this has changed recently), not really great error handling, etc and so people started using languages which seemed easier to use like Python.
The variable prefixes are just the tip of the iceberg. The real problem with those prefixes is that they, themselves, are context-dependent on attributes associated with the underlying data type at run time. So you can find yourself in a situation where the behavior of the syntax differs in ways that are difficult to control for during development.
Strongly agree. A language which has something like “wantarray” as a first-class feature is semantically…unique, at best, probably more like “flawed by design”. All the oddness with typing and sigls descends from that.
Same for autovivification. Insane feature. Useful for some problems but causes many more.
Which is a shame, because perl5 semantics had some nice features too! But there’s only so much you can do with a structure whose foundation is so wacky.
I remember trying to use the new "reference" feature (when it was new), with "blessing" and so on and so forth, to try to create real data structures, and finding in some way or another that it was just not regular. I can't recall the details, but something along the lines of a feeling that the syntax worked differently for, say, the top level of a tree (or first index of a multidimensional array, etc.) vs the rest of the structure.
In the main, the sigil refers to the type of the eventual value, regardless of what contains it. The tl;dr is that you mostly use `$` unless you're wanting more than one value, or to dereference (when you use the sigil for the type of reference). Some examples:
Where things become a bit less regular is the difference between reference and non-reference for hashes and arrays when they are top level. At the top level, you need a `->` but that becomes optional at levels below (because at levels below, they have to be references). And then there's stuff like getting a slice out of an arrayref So... yeah.> Where things become a bit less regular is the difference between reference and non-reference for hashes and arrays when they are top level. At the top level, you need a `->` but that becomes optional at levels below
Yes, that's probably what I was remembering. Thanks for the exposition.
You unlocked hidden memories within me.
I never understood why Perl has all these crazy features. It feels like someone going "hah it would be funny if it worked like this..." but actually really implementing it.
People always said "it's because Larry Wall is a linguist!" as if it explains anything!
You always go from "this is neat" to "...but why" quickly with perl.
Yep, there're all sorts of things like this in Perl. Its semantics has always been confusing to me.
Yep. Perl the first language I ever used to professionally do something approximating "real programming" (as opposed to one-off scripting). And then I learned Python and never touched Perl again ... at least at the time, to my very inexperienced self, it felt like an improvement on every single axis.
In retrospect, probably 90% of my enthusiasm for python over perl was just "if you use python, you never have to think about variable sigils ever again." That and `string.split()`.
> bits like those variable prefixes ($@%)
Perl originated from shell programming and inherited some of its patterns. If you ever looked at a bash script using arrays you will immediately recognize "@" to access the array as a whole and the switch to the "$" sigil to access a single element from that array. Perl was designed to make it easy for shell script writers to pick it up.
> the lack of function arguments (I know that this has changed recently)
Real arguments were added as of perl 5.20, which was in 2014.
Yes, that's almost as old as some currently-hyped programming languages. But it's quite new compared to the natural behaviour of some developers (a fact that I used to find surprising and now just find disappointing).
Comparably: today, in the Python world, people are praising tools like uv because now they "don't have to understand virtual environments". And continuously since the introduction of PEP 668 three years ago, people have been grumbling about the expectation to leave "externally managed environments" alone. But uv still uses virtual environments; and `venv` has been in the standard library since 2012, and the third-party `virtualenv` that it's based on has been available since 2007.
As an experimental feature, with no guarantees it would remain in the language. It wasn't marked a stable feature until v5.36 (2022).
That's "recently", relative to Perl's heyday.
Sure, but perl was already dying by like 2005.
I haven't written perl in a long time but I cannot put a finger on why I stopped using it.
It used to be my goto language for quick and dirty scripts that needed somewhat non-trivial text processing.
Anyway, this made me think of the 2008 Damian Connway Perlcon keynote:
If you've never seen it it's worth a watch: https://www.youtube.com/watch?v=HzTjPx4NIiMI still use perl. It's my go to for string parsing (think pipe log file, do something with it and send it to stdout). It's also my go to for anything that I still want to work in 10 years.
What killed Perl for me was readability, long before Perl 6/Raku. I was an Awk programmer from way back, so took to Perl quickly once it was available. Then in the late 90's I wrote a utility program in Perl that generated some nice HTML documentation for me from some kind of input format I no longer recall.
A year later I tried to use that script on another project, but had to make some changes; and couldn't make heads or tails of it. Shortly thereafter I had occasion to look at some Tcl/Tk I'd written at about the same time...and it made perfect sense to me.
Had I used Perl on a daily basis, rather than occasionally, I might have stuck with it. Instead I switched to Tcl/Tk, and never regretted it.
In all seriousness mod_php killed Perl, or at least struck the fatal blow. In the late 90s I wanted to make dynamic web content, just simple CRUD stuff. The most reliable way to do this was Perl. As long as your hash bang and permissions were correct you could drop a script in a cgi-bin directory and it would work. It didn't matter if the server was Solaris, Linux, or some other Unix. Most hosts that supported Perl also at least had the CGI module installed as well.
It was worth fighting with Perl's syntax because it was the best option for web programming (for random amateurs like myself). Web hosts often didn't have C compilers available so C wasn't an option. TCL was workable but not as prevalent as Perl on web hosts. Same with PHP3. Keep in mind this was an era where you were deploying on machines you didn't on which you didn't have admin access. Most of the time you didn't have shell access on machines you'd deploy on.
As Linux adoption on servers exploded so did the deployment of PHP. It was easy to deploy PHP web apps since they could be readily dropped in your htdocs or public_html directory and be handled by the server. Enabling other CGI outside cgi-bin directories was uncommon.
So by 2000 or so there was no reason to learn Perl to do web stuff easily. You could do it in PHP which was already a templating language. The younger version of me that wanted to do web CRUD stuff bought a PHP book instead of a Perl book. With Python 2's release at that same time if you wanted to do portable non-web stuff you had a much nicer language than Perl available as well.
I have two programming language tattoos: A Perl camel, and a Ruby ruby.
For me, that's the answer to this question: Ruby had all the stuff I liked from Perl, and didn't have the stuff I didn't like. It's just that simple.
Shhhh don't mention Perl. The fact that Perl is still installed by default on most Linux distros is the only ray of light in the horrible devops landscape. The fact that I can write a script in Perl and not have to deal with BASH's horrible syntax is a small joy in that world. If you mention Perl too much, the people who ruin everything might set their sights on it.
freedesktop folks will eventually replace perl with a system service.
Perl is powerful, expressive, and cryptic. Its popularity faded during a time when the popular trend of programming languages was towards simplicity and legibility. C++ gave way to Java and C#.
Also, Perl's strength was text processing in a world where data was moving out of simple columnar text formats and into databases, xml, json, and other formats better represented by object models than lines of text.
Personally, back when Perl 6 was harmless vaporware, I never found a place for Perl 5.
For moderately advanced text processing with regular expressions, supposedly its strong point, it was far less elegant and concise than AWK at the low end and far less readable and less batteries-included than Python for more complex tasks involving some integration.
For dynamic web pages, another of the main uses of Perl, PHP was purposefully designed and (while not really good) practical and user-friendly, with plenty of other obviously more robust and serious options (Ruby, Java, later Python, etc.) for more enterprise projects.
It sounds like Perl just wasn't your style and that's okay.
But, Perl was immensely popular, particularly in the 1990s in its 4.x/5.x days. We used it because it was precisely more elegant, ergonomic and performant than awk :-)
Later on, Python gained more traction because it was more batteries-included, and PHP evolved from being a toy named "Personal Home Page".
Perl was immensely popular, but it isn't necessarily enough to qualify for the personal "bubble" of languages one learns. It was a good choice of proven, general purpose interpreted scripting language for you in a time when Perl competed with AWK and shell scripts, but in the 1990s I used mainly C and C++ before adopting Java quite early and almost exclusively; when I later decided to learn some proven, general purpose interpreted scripting language Python was my obvious choice: more advanced than Perl 5 and more popular than Ruby.
Even before the Perl 6 insanity dropped, there was a serious underlying problem in the Perl ecosystem: CPAN. There was this module (I don't remember its name, or author) that was pretty important: you'd end up using it if you were serious about Perl.
One day, around 2000 or so, the author/maintainer, a well-known guy in the Perl community, updated the package with an incompatible API. If you used that package, you had to update your code. There was no backward compatibility, nothing. To make things worse, the README stated that it would AGAIN change API in the future, but he didn't know yet what the change would be.
I considered this disastrous maintainer behavior, as I'm sure anyone reasonable would. It was clear I had to stop using this package, and anything else this guy could get his claws on. But there really wasn't a massive outcry that I could see, nobody calling him out for this crap.
That's when I knew I had to stop writing code in Perl. I tried Ruby but found it unstable at that time. Next project I used Python, and never looked back.
I still use Perl everyday. I know it isn't as popular as when I learned it in the 1990's but I process so many text logs that I find it very useful.
I use Raku on a regular basis. I think it is the best language to write DevOps (for lack of a better term) scripts.
Perfect for people who find Bash too sharp and fragile and Python too tedious.
After twenty years of Perl, I switched to Python because I was encountering too many useful frameworks and systems that had no corresponding Perl packages. The last straw was when I wanted to use Mongo and found that the Perl package was unsupported.
What is dead may never die. Perl will live on in the few mostly weird places doing things other languages can only dream of. And that’s fine. Perl doesn’t need to win the race or update itself. It is good enough as it is. It’s the magic wand in the world full of electronics. Sure you can light the room with an electric PHP/Python lightbulb script. But Perl can summon a levitating glowing orb out of thin air with a single line of code.
I have great love for Perl, but I'm not super eager to go back to using it.
I used it in probably one of the more cursed contexts I've ever heard of. Understand[0] is a static analyzer for many languages, and one of its killer features is that it is programmable with a Perl API. I used this feature at a defense consulting job to help target audits of huge, multi-million LOC codebases.
Perl's expressivity was very useful here. I cut my teeth on functional programming concepts to write some very nice traversals. The runtime environment of the host program was a nightmare to deal with though.
[0]: https://scitools.com/
It was never about Perl, it was the plethora of alternatives.
Python evolved, PHP had 1000 times more "how to get started" articles, Node happened. And LAMP became the default for noobs.
I learned Perl back in the day. It was fun and powerful.
But I think the package management and culture killed it for me. People took pride is writing obnoxiously messy code. Package dependency hell. Gung ho borderline toxic RTFM culture.
Perl didn't die. It transformed to Raku.
This is evolution. Not death. It found what are its strengths that would make it relevant today and it made the leap of faith. That is remarkable.
No one need to switch to Perls 6 and Perl 5 can evolve incorporating incrementally stuff from Perl 6. Not every core team has the time, the $$$ or the devs to put forward long term plans of compatibility.
People always expect "someone" to do it.
What Perl 5 people could do, is improve its code base, clean it up and use sane software engineering practices to make code boring, modern and much more friendly for contributions.
You know, the anthropic side of software.
Nobody we've hired in the last 10 years wants to touch anything Perl.
That said, we re-wrote all of our monitoring scripts in....Bash.
Ugh.
I think what killed Perl is that no one wants to invest into it. And not because of Perl 6.
It is a great language for quick and dirty scripts, one liners... But no one wants to start a big project in Perl, and I think for good reasons. With only the "quick and dirty" use case remaining, people didn't want to invest into a language for that, it is throwaway, that's the point. So it was left to die slowly.
I don't think that Perl 6 took away the Perl community, I don't think the people on Perl 5 and the ones on Perl 6 were of same kind, the former just wanted to continue using their "Swiss Army Chainsaw", while the latter wanted to design an innovative language. It has created some confusion, but I believe it is minor.
If I want to point at one thing that killed Perl, I would go with PHP. Websites were a common use case for bigger Perl projects. Now that PHP does it better, what's the point of Perl for that application?
Perl 5.
Perl 4 was a great upgrade to bash as a scripting language. Perl 5 added a bunch of complexity to remake Perl into a programming language. It failed.
Perl 4 was a great scripting language whereas Perl 5 was a terrible programing language. Perl 5 lost to the better (dynamic) programming languages and bash reclaimed the scripting title as Perl 4 was dead.
No.
I came to Perl when Perl 4 was the latest.
I was using it as a frame work for distributed computing, moving data between machines.
I was on the point of throwing it all away for C++ when Perl5 came out.
I forget the details, but it made everything possible, and did not get in my way like Perl 4 did.
Interesting take! I wasn't around for perl 4. I didn't like perl 5, but I was quite interested in 6 at the start. For a moment it looked like Larry Wall had really reflected on the problems of perl 5, and was going to make a new language that was at once cleaner and more systematic, even though it had more features. Then he kept adding more shiny things and I lost interest.
As someone that was already working during the dotcom wave, Perl is a tool I would still reach for, given the problem I might trying to sort out, if on an UNIX like platform.
> Binary package managers that chase down dependencies on their own weren’t a thing until the early 2000s, I think?
UNIX package managers started to be made available during the 1990's.
Yes, but they were either source package managers or they didn't resolve dependencies transitively, only complained about missing direct dependencies.
I might be using strange versions of Red-Hat, Mandrake, SuSE, Aix and Solaris, then.
I definitely had Debian installs pulling binary package dependencies automagically via apt-get in 1999, and I think similar with RedHat a year or so before that.
Though that doesn't cover much of the 90s.
Debian had binary packages with dependencies via dpkg from maybe 1994. Automatic recursive downloads, with apt (apt-get) were much later, around 1998. Rpm was launched in 1997.
It's hard to remember really, but automatic downloads would have been considered quite a misfeature by lots of user sites, in an era of intermittent, metered internet connections.
Didn't dselect in Debian deal with transitive dependencies (albeit through a tui rather than a cli) a couple of years before deity/apt came along?
As I recall, rpm could list dependencies but not automatically fetch them. Full apt-style recursive downloads weren't a thing until yum from Yellowdog (a PowerMac-specific clone of RedHat) and urpmi from Mandrake, both of which arrived in late 1999 or early 2000-ish.
RedHat eventually started using yum as well, but not until around 2002.
Certainly, in the late 90s, apt was king. Debian was struggling badly with their internal processes at the time, though, so they didn't benefit as much as they otherwise might have.
I think you're right about rpm and yum, actually, my memory failed me. (I was always a Debian user, so didn't have as much direct RedHat experience). I remember yum being really slow when it first arrived too.
I don't remember dselect _downloading_ dependencies, but it may have been capable of resolving the full graph - AFAIK .deb always included dependencies
Correct, however those dates are still before 2000, which was my point.
Yes, I am agreeing with you, whilst adding some detail.
Perl died because more shared web hosting installs supported PHP than Perl.
From a recruiter’s perspective, I remember recruiting full stack Perl people for a San Jose based tech company in 2010. I was able to secure one really good Perl guy who had just been laid off from Yahoo, but there just wasn’t anyone else who was relatively easy to find with the experience this company wanted. I was charging by the hour, and I distinctly remember suggesting that the company consider hiring non-Perl people and letting them learn on the job as I wasn’t going to be able to find what they wanted. They kept looking for Perl people and I kept charging them. I wasn’t shocked when an executive at the company eventually asked why the recruiting bill was so high given the lack of results.
I interviewed for Yahoo Mail in '05 - multiple rounds and they ghosted me. IIRC, it was all going to be perl stuff.. I'd done some out of necessity a few years earlier, and hated it.
In hindsight, glad they didn't respond - got a much nicer EDA startup job a month later working with Tcl/Tk (which I had already used for ~10 years at the time).
I had to use Perl in a recent project to perform health checks on a container. The container authors decided not to provide /dev/tcp or curl, and I didn't want to add the extra headache of maintaining an upstream fork with curl, but they did include Perl. So I (claude) wrote a one liner script that imported the networking lib and performed the check instead.
(Side note, I know "slim" containers are all the rage these days but please please please please just put curl in your unix containers or provide a script that lets me check the container health. I don't want to spend more than 5 minutes setting this up or I'll just look for something else)
Simply python being pushed / sponsored by google? Was python all that popular before that? It had fans, of course - but was it an automatic go-to?
Python claimed to be simple - which fit well with the "line noise", erm... propaganda.
It killed itself. I always remember the joke about any random sequence of characters and numbers being a valid Perl program.
More importantly, there's hardly a problem that can't be solved in a much better way through other means.
I use shell, vim, sed all the time (awk less but i have used it). I've never used perl. I don't even know if i've ever even encountered a perl program that i wanted to look inside.
I think its just one of those things, they lost mindshare and people stopped making stuff in perl. Network effects made it snowball from there. How often do you see code examples written in perl? Almost never. I see people write blogs with code snippets in python, c, rust or even shell all the time. Never perl.
Momentum matters and perl lost it. I think of perl the same way i think of cobol or fortran.
You really think that Perl has billions of lines in active use in critical applications and libraries?
Around 2010 I ditched Perl for PHP because I had been using PHP for web and could write the same systems scripts in PHP as I used to write in Perl. Sticking with one go-to language is easier on the brain.
I love Perl. I think, though, that the crazy mix of sigils and braces/brackets to work with complex data structures was one of the main reasons.
Especially for the type of users were Perl had gained some ground in the past...data science, DNA related stuff, etc. Non programmers.
If you look at just about any other language and how you would pull data in and out of json yaml, manipulate individual elements, etc... the Perl is just hard to decipher if you don't have immediate recall of all the crazy syntax for dereferencing things.
Perl is what killed Perl. I have never had as many "tear my hair out at 4AM" debugging sessions as I have had with Perl, because I missed some weird character somewhere.
Disclaimer. Perl was my first real language. I have several contributions to Perl, including a complete rewrite of Carp.pm. For a number of years I was also on the Perl 5 Grant Committee.
I completely discount the basic syntax as an issue. Sure, it is an easy thing to complain about. But I've personally seen a number of people with no background master the basic syntax very quickly. In fact I was able to teach myself from the Camel book with absolutely zero background in the various languages that are supposed to help you. And during the dot com era, most of the people writing CGI scripts in Perl, similarly lacked a programming background.
The first issue was the fact that a lot of bad Perl got written. It was remarkably easy to pick up a bit of Perl, then write a bunch of code. This code was generally bad, useful, and full of security holes. (Thanks, Matt Wright.) Most people's exposure to Perl was to this kind of code, and it left a permanent bad impression.
The TIMTOWTDI (There Is More Than One Way To Do It) philosophy fed into a widespread cowboy philosophy. People took pride in their mastery of Perl, and demonstrated it by using obscure features. Like, say, C++, many subsets of Perl make for good languages. But if you try to use all of the features at once, the combination doesn't play well together.
That said, there was a significant group of people who grew and improved together. They learned best practices, wrote good CPAN modules, and elevated their game. But this group fell into a different trap. They learned the immense productivity of small teams. But organizations filled with small teams of senior programmers, don't have a way to mentor junior programmers. This cut off the pipeline of future developers. Losing that pipeline is an organizational threat. How do you find maintenance programmers down the line? Many organizations that had a lot of Perl, then put a lot of work into trying to move away from Perl. A significant number of Perl programmers saw the writing on the wall, and took the opportunity to move away from Perl themselves. This resulted in very few new companies being built around Perl.
(Incidentally the same "no pathway for junior programmers" problem is becoming a big issue for programming in general because of LLMs.)
For the next problem, we have to go to perl5-porters. The group that maintained the core of the language.
Let's start with a key individual. Tom Christensen. Brilliant, productive, and a technical genius. But also confrontational, unstable, and a toxic influence that shut down Perl development. This was a major reason why the Perl 5.6.1 release took over a year to get important bug fixes out. Tom also drove a number of people out of the Perl core.
Then there was an underlying tension between two major groups. The first were people who wanted to take Perl, and run with it. Adding all sorts of new and interesting features. The opposing group was those who cared about production, and wanted to be reaaally careful about breaking anything.
This lead in 2000 to a famous cup throwing incident by Jon Orwant. Larry's solution was to behind the scenes put a muzzle on Tom, and start the Perl 6 effort. That way people who wanted new features could go off and play in the new sandbox, while those who wanted to support existing Perl could stay in Perl 5.
Over time a lot of the good ideas in the new sandbox got ported back to Perl. See, for example, Moose. The spread of these technologies meant that there was a lot of progress within the Perl ecosystem. Unfortunately this came as the Perl ecosystem itself was shrinking. The language itself improved a lot. But the programming world in general didn't notice, and didn't care.
wow that’s great
Thanks for that perspective, Ben.
You're welcome.
I should have also mentioned that I was tilly on Perlmonks. For a long time I was the top rated poster, on the dominant question and answer site for Perl questions.
I for one knew that. I’m mr_mischief on there, not that I visit regularly these days.
Oh wow! I remember you!
I hope that life is treating you well. My life since COVID has been a nightmare.
Life is alright I suppose. There’s been a lot of cancer in our families, which is rough. There’s been some wonderful responses to treatment though. My job since late 2022 I mostly really like. My fiancee and I moved from Texas back to Illinois in June. We got engaged in late August.
I’m sorry to hear how life’s treating you. I wish you well.
If you want to connect on some social media platform, I’m on FB, Mastodon, and Bluesky. Or I do check Perlmonks still once in a while, and Slashdot.
I may blog about this next year, again[^1], as I'm working on a project that sort of covers it - not in a way that will answer the question but more observational.
Anyway, I feel Perl's popularity was hugely exaggerated in the mid to late 90s and early 00s. The alternatives were either not there in terms of language and toolchain features, ease of use, "whipuptitude" or whatever, or library support (CPAN was a killer app), or they were too old school or enterprisey. Sysadmins were using it everywhere so it got into all sorts of systems that other languages couldn't without much more faff.
Its back compatibility meant it stayed in those places for a long time. It's still in a lot of those places.
The fall in popularity the last decade or two was more of a regression to the mean, or perhaps below the mean. Many other languages have come along, which have contributed even more to the fall in share.
Yes, yes, Raku (né Perl 6) but I'd argue that also contributed to a lot of really good stuff on CPAN. The Perl 5 core did get neglected for a number of years, as @autarch says, which may have been a factor.
[^1] previously: https://leejo.github.io/2017/12/17/tpc_and_the_end_of_langua...
What put perl out to pasture for me was lack of static types, nor any capability of adopting them. We were told to wait for Perl 6 for that, and well, we saw how that went. I'm told that disabling indirect object syntax gives Perl a fighting chance at static analysis, but that in the end it's still the case that only Perl can parse Perl.
Perl was write only.
I worked at a company that had a 50k bash/perl install script maintained by the 3 person QA team.
Dear lord that was a mess.
I had to build a custom middle ware sso thingy that ran on six and worked with ssl certs.
I fought cpan for two days trying to get anything to work.
Switched to java, had it done and in production in an afternoon.
Not a fan of Perl.
Did some major projects for my employer using Perl (coupled with Java of all things) in the 90s. Then I learnt Ruby and put aside childish things (jk). I then dropped Ruby for Elixir and Python for the sort of projects that I would have used Perl for, back in the day. As a semi-retired sort, I now keep my Elixir and Python skills up-to-date and can't remember the last time I even tried to read any Perl. I know it's still there, doing work, but then so is COBOL.
What I miss from then are the O'Reilly books about Perl. Peak O'Reilly. Every one a joy to read and packed full of goodness. Without being 1,000 pages long. Oh, and CPAN.
Perl 6 was only ever a distraction - I was already out of love with Perl by then and Ruby (and obviously Rails) came along at the right time for the next project.
I was a happy perl user for a long time, probably until sometime in the early 2010s. I am a sysadmin and perl was a great tool for what I needed to do.
Jim Weirich was a heavy perl user for a long time, and we were both involved in the Cincinnati perl mongers group. He found ruby and fell in love. He thought Ruby would be a good fit for me and we had a long conversation about why he preferred it to perl. It took me a few years, but I eventually took his advice. As usual, Jim was right, and I haven't written any perl since then.
tl;dr: for me, ruby killed perl.
Something I haven't seen mentioned is that python is very commonly taught at universities. I learned it in the 2010s at my school, whereas I never got exposed to Perl. The languages people learn in school definitely stick with you and I wonder if that plays a non-zero factor in this.
Been using Perl since the beginning… essentially every time I needed to write a shell script more than 10 lines long I used Perl … eventually was also using it for web back end stuff too … kind of like duct tape. I still use it today if I need to write more than 10 lines of a bash script.
Same here. I use Raku instead.
All of rsync.net and "Oh By"[1] are coded in perl.
Which is to say, the customer facing web interface, ordering, management and our own management back ends.
Obviously the actual storage component employs no interpreters of any kind.
Alive and well!
[1] https://0x.co
This reminds me of the april fools email from Richard Stallman to rewrite Emacs with Perl https://www.gnu.org/fun/jokes/gnuemacs.en.html
I have been using Perl for almost 30 years now, privately and professionally. People here tend to say, Perl 6 or Python killed it, but that's not what I experienced in those 30 years. Not that simple.
It was a combination of things, the Perl 6 announcement was one of the smaller parts actually.
- TIMTOWDI lost against "batteries included", and it lost big: It's not so much that the simpleness of the Python language won over Perl, the real and absolutely major problem at that time was the success of CPAN, which "killed" Perl 5. Perl 5 would have needed ONE object system, ONE base exception class, ONE way to do function signatures. Instead at the time, it came bundled with a bunch of Perl 4 utilities which nobody dared unbundling, CGI and a handful math functions. Being able to pick is nice, but everybody else did pick, too, and so if you used any CPAN dependencies, you soon had 3 incompatible object systems, 4 type systems, 5 exception systems co-existing within your project. A problem Perl has to this day and the reason why my team tends to re-implement stuff instead of pulling in dependencies. Python's "batteries included" approach easily won out, because stuff worked with each other and you didn't burn then scarce RAM on having different implementations of the same thing.
- Perl started to lose at the low-cost hosters against PHP already pretty early. It was easier during a certain time period to have a halfway performant PHP installation than a performant Perl installation. Hosters usually only offered CGI for Perl, not mod_perl, while PHP usually was offered as FastCGI module or mod_php which supposedly was easier to install. No low cost hoster wanted to mess with mod_perl, because it always was a hassle to setup.
- Speaking of mod_perl, things in the web dev sector still stayed pretty stable as long as Apache 1 ruled. People had to use mod_perl, but then you had a pretty performant solution. Then Apache 2 came around but mod_perl 2 wasn't ready for a long time (honestly I don't know whether it ever became ready). The Perl community at that time appeared entirely unprepared for that. While Python users were accustomed to run standalone Python servers behind proxies, Perl always was relying mostly on mod_perl. But threading in Perl stagnated and ran against a wall, and Apache 2 preferred multi process multi threading modes versus the simpler prefork multiprocess model that Apache 1 and mod_perl 1 ran on. This was the time were you could basically feel the creaking and everything breaking apart: suddenly there was no clear path forward, with mod_perl2's stability issues and the general threading stability issues of Perl 5.
It took years for the community to recover from that and focus on things like the Python-inspired PSGI/Plack as a way forward.
So, how does Perl 6 fit into this? Yes, in the early 2000s we did think, it would be just around the corner and be a clear upgrade path and solve everything wrong with Perl 5. Nice fantasy at the time. But at the same time, people were busy with far more pressing immediate problems, like how to migrate away from mod_perl1. When Python's WSGI and soon after that, Ruby on Rails came, they pressed directly into the vacuum left open by the mod_perl 2/Apache 2 disaster and this is actually what sealed the deal, IMHO.
> No low cost hoster wanted to mess with mod_perl, because it always was a hassle to setup.
I am not aware of any way (back then) to run mod_perl, which was powerful enough to facilitate developing Apache modules directly in Perl, safely in the shared hosting environments that most people used in the 2000s. If you wanted Perl, your options were either classic CGI, with the overhead of script recompilation and a new perl process spawned for each individual HTTP request (even if initially handled by the same Apache process), or paying up for a dedicated server/VPS just so you could run mod_perl.
How the Perl community thought this was an acceptable state of affairs, especially given how big of a driver webdev had been of Perl uptake during the .com bubble, when Perl was affectionately called the "duct tape of the web," and how they just sat by and let PHP eat their lunch, I'll never understand. But the attitude of the Perl community then was this mix of old-school UNIX/USENET "RTFM" culture and a dubious sense of cockiness (instilled through catechisms and catchphrases, like JAPH), so they weren't going to bend-over backwards to attract and accommodate new blood, expecting Muhammad to come to the mountain.
The reddit comments on this are worth a read: https://old.reddit.com/r/programming/comments/1p1yjb4/what_k...
Moved out of TCL and into Python in 2001. Perl was big at the time. But Python had REPL and numeric/numarray which swung it in my case.
(Worked out well I suppose? Almost 1/4 century and still using Python)
Back in 1994, Perl was an amazing thing to me (as someone who was accustomed to mainframe scripting languages up to that point), and it helped make me very productive. But it sometimes would seem like the epitome of "Write once, read never". Tim Bray even remarked on its abstruseness back in 2003:
https://www.tbray.org/ongoing/When/200x/2003/07/31/PerlAngst
My personal reason was observing the huge amount of investments into Javascript and its infrastructure (by Google and others). After Node.js was released it was a rational bet to make that Javascript would dominate, both server and client side. As someone who often does both front end and back end, it felt good to move to Javascript. It's got to be said that keeping a "common" directory around with shared code for both front- and backend is still a PITA, but still better than most other alternatives.
Is it worth learning Perl 5 these days? Maybe to use as a better Bash?
It's definitely more powerful and has less foot guns than bash, the problem is the stigma is worse than bash. You will face more scrutiny and possible derision from your colleagues for using Perl than bash. It's not just questioning your taste or style either, it's because of the fear they might have to one day maintain or try to understand your Perl.
I speak from some experience. Because I'm a 90s UNIX nerd, I quickly hacked up a a bunch of stuff in Perl maybe 6 years ago to solve some text processing tasks for a compliance audit. It worked well and got the job done within the time constraints. I actually got some kudos for getting our team out of a jam and doing grungy work people weren't keen to do. My teammates though, they lost no opportunity to dunk on the fact that it was done in Perl, and questioned my decision at every opportunity. I ended up rewriting the whole thing in Python for our next audit.
The opinion of coworkers is not a factor - but I have a friend who says that he has to relearn Perl every time he needs to use it. Do you have to use it every day to maintain fluency?
It doesn't take too long to get back into the swing of things. After a while, if you learn enough programming languages, they all tend to meld together in your brain, and the cost of switching isn't too disruptive. You know what you want to do, it's just the details that temporarily get in your way.
Yeah, as someone who occasionally had to hack on perl scripts - and I mean, maybe add/modify a hundred lines to add a new feature, then nothing for a few months, I found this too. Stop doing it for a while, and I had to relearn it all over.
I'd probably have an easier time getting back into REXX that I last used in 1992 or something..
It’s strong as a better shell. Perl is even getting an increasingly good and complete default object model in the core language. One of the big complaints was always that the TIMTOWTDI included object libraries, of which there are many. Most of the popular ones are working on becoming wrappers around the new core one, and you can write new code directly with what’s in core.
> Maybe to use as a better Bash?
If you know Python, just switch to xonsh (https://xon.sh/). I've been using it as my primary shell since 2018.
The question is "what do you want to use it for?"
There are a few places where you might dig and find a perl script under the covers. Some that aren't replaceable with bash (and sed and awk).
I suspect that my "diff these two java deployments and create a file by file update script to run on the remote machine" in perl is still running for doing incremental deployments... and if someone uncovers it its still something reasonable to understand.
However, if I was tasked with that today... dunno. I'm not sure I'd reach for the same tools as I did then.
> In devops is turtle all way down but at bottom is perl script.
https://x.com/DEVOPS_BORAT/status/248770195580125185 (2013)
> If you can not able use Perl for answer, you are ask wrong question.
https://x.com/DEVOPS_BORAT/status/280900066682757120 (2012)
... and while I can't find the original - this might be your answer.
> We have 3 strike rule for devops: 1 strike we are take away Perl. 2 strike we are take away bash. 3 strike we are give PowerShell.
https://gist.github.com/textarcana/676ef78b2912d42dbf355a2f7...
In the early 2000s Perl was godsend. A dynamic language that helped solve a lot of problems very quickly. But as soon as projects got larger and/or others joined your codebase you realized it does not scale. For me that was the moment when I slowly migrated to Python. So for me Perl‘s syntax (&@!#%), the easter eggs in the language, and the thousands of ways to be able to write things, killed it. It was just not maintainable.
I heard a fascinating theory a few years ago on the decline of Perl:
In the early aughts, Google SRE recruiting had such a strong, selective focus on A-player sysadmins with Perl expertise that it drained the market of top talent. Within google these people began to adopt, and eventually create and evangelize newer, Googlier programming languages.
In other words, Perl expertise was the skills filter, and Perl itself a technological ancestor of certain modern languages like Go.
I don’t think Google was ever a Perl shop. eBay and Amazon were, apparently. Netscape wrote Bugzilla in Perl. I’m sure there were others.
I worked at Booking.com for a year or so around 10 years or so, and most of their stack was in Perl. Folks there had mixed feelings about it, I'm not sure what things are like now, but I assume they're working to replace it.
IMDB is the one I always think of.
chunks of Amazon were still in Perl while we were building out IMDb.
Yahoo! had a shitload of Perl.
Ah yes, that's it. I had to hack on Bugzilla to customize it for our start-up.. Back in the day BEFORE they added a lot of end-user customization... UGH..
Nonsense. Google only ever hired one perl5 committer, who never actually committed anything.
I think Perl was very tied to Unix idioms. I love the language to this day and found it incredibly expressive for developing small order of magnitude programs.
Python was more opinionated, and better able to integrate with external libraries. A lot of the heavy lift in python is really invoking external code from elsewhere. You can solve “real” problems with readable code without the learning curve of C or Java.
Perl was killed by mod_php.
Not the language, but the easiest setup ever.
Perl became popular because there was not really an alternative on par with its capabilities and because it was bundled with every Linux distro. But then Python came along and picked up momentum and because of that, people realized Perl's syntax is actually not very intuitive to read and understand compared to Python.
PHP, it was easier to read and use. Amazing documentation, lots of comments on the docs and tips. Syntax was familiar. Massive libraries.
PHP and Python did. PHP so much better for web development, and especially faster due to being linked with the web server instead of in cgi-bin, and python by being a much cleaner and easier to use scripting language for batch jobs etc.
I still have nightmares about the time we were trying to write the server part of a distributed filesystem (the precursor to Lustre) in Perl.
lack of new blood is what kills an ecosystem.
the ever infusion of new blood is what made Javascript & Python to be in top 3 languages today. Even though things like Ruby were easier for some. Ruby not being easily installed on windows back then stopped new blood as well.
for language designers / framework designers -- make your stuff easy for beginners then it easily grows.
> Ruby not being easily installed on windows back then stopped new blood as well.
Also the lack of something akin to Python's IDLE in the standard install, to decrease set-up attrition for beginners. E.g. see https://stackoverflow.com/questions/16042945/rubys-irb-with-...
I sometimes wonder how different things might have been if Perl had been the dominant scripting language at the time that ChatGPT, Codex, Claude Code and other tools like that became available.
Would Python have been able to compete, in a world where Perl could be readily comprehended by LLMs?
So, maybe what killed Perl was lack of VS Code forks and lack of being agentic.
So then we'd have 100x as much "vibe coding" as now? <shudders>
Even if I disagree with our AI code assistant's usefulness - it often just suggests code based on "someone else in a different file used this statement after that last API call" that is totally irrelevant to my current needs - I can usually assess AI-generated code (C++ / python) relatively quickly and determine if it's what I want or not. It generally nails the "you just created this variable and now want to print it to the log" part pretty well.
Debugging AI-generated perl?? It would be like trying to follow "obfuscated C contest" entries all day, every day. No thanks!
The flip side to this is that perl often favored brevity over simplicity. It turns out that this is also a really useful attribute when working with LLMs. I'm not sure how confident I am here, but it really wouldn't surprise me if LLMs could both generate and explain remarkably complex perl code!
python replaced it as a general purpose scripting language.
a bunch of other things (java, ruby, js) replaced cgi scripts and mod_perl as a web backend environment.
python became a "must know" to interview at google.
old perl was neglected and became unreadable.
perl itself became ugly to eyes used to modern languages.
the perl 6 mess and associated sentiment made it look worse.
it was time for it to go anyway.
It was too simple.
(map { $~ =~ s/.*/$&/r } split /\s/, $^W x $/ ) ~~ tr/a-z/x/r x $!
I'll give you my two cents - I took a job in Perl in 2017 and set about learning it and found its community to be the most snobbish and unfriendly of any programming subcommunity I had ever encountered.
The language had many strange quirks and every question I posted about its particularities was greeted with responses along the lines of "Are you even trying? How do you not get it? Did you even read the docs?"
Well, yes, I did, and I still didn't understand, because I found them unclear.
I left the job and dropped the language and moved on to greener pastures without much regret. And it seemed like many, many people I spoke to had similar experiences with it.
The last time I dealt with the Perl community, I posted a question asking for an update on some announced changes. In a community of adults, it was a straightforward question with a straightforward answer, but that's not what you get with Perl.
What killed it was that a lot of its development talent effectively went off and worked on a completely different programming language that eventually got released a Raku.
When the team departed, Perl lost its development velocity and Python wasn't that far behind.
For me the three sigils of Perl $, @, % are the “holy trinity” of scalars, lists, and dicts that are foundational to dynamic languages like Python and Javascript and are used all the time in static languages like Java or Rust when your data is dynamic.
It's just a bad language.
It's the only programming language other than C which actually needs a tutorial on how to use arrays of arrays. It's a part of the standard Perl doc, appropriately named "perllol": https://perldoc.perl.org/perllol
Most popular languages (Python, JS, Java...) as well as classics like LISP manage references transparently - the distinction between "array" and "reference to an array" is abstracted out.
In Perl, it isn't. It's a language with some archaic elements of manual memory management and parameter passing quirks. It's very clear that Larry Wall was not guided by programming language theory or math-inspired abstractions, but "whatever shit would be easiest to implement" (from https://perldoc.perl.org/perlsub#SYNOPSIS):
> ... any arguments passed in show up in the array @_. The array @_ is a local array, but its elements are aliases for the actual scalar parameters. In particular, if an element $_[0] is updated, the corresponding argument is updated
Theorists described call-by-value, call-by-reference, etc. But our man Larry came up with pass-via-a-local-array-but-its-elements-are-aliases-for-the-actual-scalar-parameters. I can see how one can quickly hack this together. But maybe it's time to retire this.
Yeah, it was always a headache to put together complex data structures in Perl. It's kind of like bash in that way. Every time you need something like "a hash table that contains lists" it quickly turns into a quagmire. In Python you just... do it.
One thing I miss to this day is how ergonomic regular expressions are in Perl 5.
Dude, a lot of the string handling stuff in Perl was great!
Let's not forget that Perl 6 was announced because Perl 5 usage was already stagnating. Perl 6 was supposed to fix that problem. But it ended up making it worse.
Perl is great and I'm sad that Python "won."
It would literally just be Python (and probably some php and maybe even ruby) plus "Bash is good enough and more ubiquitous for the things you don't need all of Python for," no?
Few years into Perl 6, they should have recognized the writing on the wall, forked off Raku and let Perl 5 grow on its own.
One of the biggest fumbles in the history of computing. (With hindsight ofcourse..)
Easier to learn languages came along.
Perl stems from a time where COBOL, FORTRAN, and SQL made sense and it was already mind bending for those accustomed to those old languages.
Modern minds can't comprehend Perl.
Expecting the Perl community, with it's TMTOWTDI (There's More than One Way to Do It) ethos, to come together and be the drivers of the next version.
I spent 10 years in perl and created a lot in it - it taught me a lot about code as a culture,importance of tests, TIMTOWTDI, etc. I think I owe a lot to it.
I found myself defending it more and more online against the folks who were nay sayers - those who complained about its syntax and it's quirks - but that wasn't a problem for unixers who used sed/awk/vim and all the other arcane tools. Perl wawa means to and end and it was the best tool to reach for (the glorious Swiss army knife).
I guess there was an infection period - the brain drain to python and Ruby meant it was harder to find decent quality libs on CPAN anymore as folks would only do things in python. And Yea, while CPAN is still rich, it's not the first hit on Google anymore.
Today, the map-sort-map Schwarzian transform is still the easiest to do in perl than any other language and it helps me whip up the throwaway scripts quick. Wouldn't change the language - I really love it!
Instead of a Swiss army knife, I always heard it referred to as a "swiss army chainsaw" lol.
Perl isn't dead. Perl is the only stable actively developed language. Code written in 2003 runs today and perl code written today runs on a perl interpreter from 2003. Because of this perl is by far the best language to do system administration. It is both ubiquitous and stable. Other scripting languages like python constantly have breaking changes and frankly, you have to have a special separate install for every python script you try to run. With perl the system perl is always enough. No containers needed.
You can call it dead. That's fine. Keep it unpopular. Popularity kills. Popularity leads to a language becoming dozens of different incompatible things. Perl is quietly amazing. I write once and run anywhere, anytime. Other languages can only dream of this.
Python.
And PHP.
Author is wrong. Raku killed it.
Python3 almost killed Python.
It’s a tale as old as time.
As I have said before[1], I think the biggest thing slowed Perl adoption was the changing background of new developers. New folks just didn't have a background in shell, C, awk, and sed. This fact took Perl syntax from being amazingly intuitive and easy to adopt and turned it into obscure nonsense. As a newb what the heck are you going to think about constructs like the file test operators[2]?
[1] https://news.ycombinator.com/item?id=44726347#44752240 [2] https://perldoc.perl.org/functions/-X
The thing that killed perl was python. The reason that python won is because it was Google's blessed scripting language.
Me, I killed it >:(
Um, does this guy realize that the dotcom boom was 25 years ago? The software field has grown exponentially bigger since then. Perl being "as popular as it was during the dotcom boom" (even if true) basically means that it's dead.
[edit: also, even his own graph of "releasers" shows that if current trends continue, there will be essentially 0 "releasers" in 10 years]
Raku
Perl was the internet in 1990s. People (me) who were doing unix systems work (C, shell, Perl and some DBs and FTPs) could now quickly throw a CGI script behind an Apache HTTP server, which tended to be up and running in many unixes :80 port back then (Digi, HP, Sun, etc). Suddenly I had a working app that would generate reports directly to people's browsers or full-blown apps on the internet! But Perl CGI did not scale at all (spawn 1 short-lived process per request will choke a unix fast), and even after mod_perl [1], that got quickly superseded by PHP, which was really built for the web (of the 1990s). Web frameworks and fastcgi arrived too late to Perl, so internet Perl was practically dead at the turn of the century.
The enterprise, who either did not have any webapps or had tried Perl CGI first and suffered it dearly, got pinged by their sales reps that Java and .NET (depending if you were a IBM, Sun or MS shop) were the way to go, and there they went with their patterns and anti-patterns for "scalable" million-dollar web stacks. That kicked-off the age of the famed application servers that resist up until today (Websphere, Weblogic, etc).
So Perl went back to being a glue language for stitching up data, C/C++ and shell, and that's how the 2000s went by. But by then, Ruby and Python had more sane communities and Ruby was exciting and Python was simpler - Perl folks were just too peculiar, funny and nerdy to be taken seriously by a slick new generation that coded fast and had startup aspirations of the "only $1B is cool" types. Also the Perl6 delusion was too distracting to make anyone event care about giving Perl5 some good love (the real perl keeping servers running worldwide), so by the 2010s Perl was shooting down to collective ostracism, even though it still runs extremely well, fast and reliably in production. By the 2020s the release cycles were improved after Perl6 became a truly separate project (Raku, renamed in 2019), the core has gone through a relative cleanup and finally got a few popular features in demand [3]. The stack and ecosystem is holding up fine, although CPAN probably needs some good tidying up.
The main issue with Perl at this point is that it has not been a target for any new stuff that comes out: any cool module, library, database, etc that is launched does not put out a Perl api or a simple example of any kind, so it's up to the Perl community to release and maintain apis and integrations to the popular stacks on its own, which is a losing game and ends up being the nail-in-the-coffin. By the way, nothing (OSS) that comes out today is even written in Perl. That reduces even further the appeal of learning Perl.
Strangely enough, lately Perl has seen a sudden rise in the TIOBE index [4] back into a quite respectable 9th position. TIOBE ranks search queries for X language and is not much of a indicator, being quite noisy and unreliable. My guess is that those queries are issued by AI agents/chats desperately scraping information so that it can answer questions and help humans code in a language that is not well-represented in the training datasets.
[1] mod_perl was released in 1996, and became popular around 1999: https://perl.apache.org/about/history.html
[2] PHP was released 1994, took off ~1998 with PHP3: https://www.php.net/manual/en/history.php.php
[3] Perl's version changes simplified: https://en.wikipedia.org/wiki/Perl_5_version_history
[4] https://www.tiobe.com/tiobe-index/
Perl.
[dead]
[dead]
[dead]
[flagged]
[dead]
[flagged]
I have a problem. I know, I'll post a dismissive, overly reductive platitude and farm points on HN.
Perl 5 is a great language far ahead of it's time, it's extremely functional, and it still underpins many large and important systems to this day. No, it's not perfect, but it's the first time programming where I ever felt like I was having fun writing the code as opposed to achieving a means to an end.
I admittedly have no experience with Perl 7 and didn't like Raku. Sometimes worse is better.
Perl 5 was abandoned for a reason by people who developed it. Something I you never see happen in other languages. Planned successors did not catch up.
Perl does not scale. Very few people want to maintain Perl code. The write only reputation is not without merit.
It is without merit. There are more than a handful of modern internet companies running on Perl. Amazon runs a LOT of Perl for CDO. Who has scaled more than Amazon?
This is a very ignorant take that selectively chooses to look at the fact that you can write Perl poorly, because the language does not stop you from doing so, and ignores the fact that you can also write it in a maintainable fashion.
People stopped working on Perl for a variety of reasons. The commitment to backwards compatibility to a fault. The reputation leading to lower adoption. And so on. None of these are structural problems with the language itself, they are more community/bad luck issues.
"I have a problem. I know, I'll use Perl. Now I have two problems." Is an old Perl joke from the 90s.
I like the java version "problem factory"
If you step back and cross your eyes, Perl, Python, and Ruby are more similar than they are different.
>"In Perl 6, we decided it would be better to fix the language than fix the user." — Larry Wall
As history has shown, this didn't work out well for anyone
[flagged]