Well, I mean there's frequently the obvious way to do something, then there's a large number of less obvious ways, then there's the obvious way of doing it if you're mostly programming using Pandas, or NumPy, and Python is more of an implementation detail.
I agree with the intention of the quote, sadly it didn't work out like that.
I can't read this article due to the paywall, but here's my lukewarm take based on the title at least: "nobody" codes in Perl any more because the language lost a lot of mindshare in the transition from Perl 5 to Perl 6, a.k.a. Raku. And regardless it's always been a fairly idiosyncratic language in a lot of ways. Stuff like Ruby (which inherits DNA from Perl along with Lisp and Smalltalk), PHP (also takes some notes from Perl, perhaps more superficially), and Python ate a lot of its lunch.
It was the first language I wrote professionally and I always thought it was a lot of fun, but if I want to be humbled these days I reach for Haskell (like a lot of the Perl community it sounds like...).
EDIT: okay I read the article, thanks to welpo for the archive link. Yeah this is kind of a nostalgic piece so I think my original comment is still relevant. I do like Perl still, I will always have a spot in my heart for it. I appreciate especially how seriously Larry Wall tried to think about approaching things vis-a-vis linguistics even if I don't necessarily think that's the best approach for a language used by an engineering team these days.
I hope it sticks around in any case. It is truly unique.
Indeed Perl has true lambdas and full closures and has for many many years. There’s no GIL. It supports multi-process programming, event-driven programming, and multithreading. It has optional objects. Code can be, but doesn’t have to be, written in prefix with surrounding parentheses. It can feel very natural for people coming from some form of Lisp.
Unfortunately it doesn’t do automatic tail call elimination but that’s a tooling limitation more than a language limitation.
> But perhaps the lesson of Perl is timeless. It asks us to be less precious—and more human—when it comes to programming languages and their design. Only then might we be able to bridge the gap between us and the machines.
I'm not clear which way the author thinks this works but having started coding in the 90s I feel that with Perl you had to try to understand the quirks of language and the language didn't try to reach out to programmers to make things easy. Whereas other coding languages aim to be intuitive, with clearer syntax, more logical naming and frameworks to obscure complexity, which to my mind is a better way to bridge the gap between us and "the machines".
Perl was my first scripting language, I occasionally need to run some of those old scripts (15-20 years old), they always run. Python scripts last 6-12 months.
>Partway through, Jon Orwant comes in, and stands there for a few minutes listening, and then he very calmly walks over to the coffee service table in the corner, and there were about 20 of us in the room, and he picks up a coffee mug and throws it against the other wall and he keeps throwing coffee mugs against the other wall, and he says "we are fucked unless we can come up with something that will excite the community, because everyone's getting bored and going off and doing other things".
Intermission: The Jon Orwant Mug-Throwing Incident in 2000
By 2000, it was evident that Perl needed an infusion of life:
"The [P5P / Perl Conference] meeting was originally a gathering of Chip Salzenberg, Jarkko Hietaniemi, Elaine Ashton, Tim Bunce, Sarathy, Nick Ing-Simmons, Larry Wall, Nat Torkington, brian d foy and Adam Turoff, brougt together to draft a constitution of sorts since the community seemed to be fragmenting. Jon showed up to the meeting late and found us talking about the community and started throwing things to express his discontent with how perl itself was stagnating, possibly even dying, and that we should be talking about reviving Perl. The cup incident was planned theatre from what I was told later. So, it was already a fait accompli but the tantrum was it's outing." [1]
*>I am interested to learn more about this incident.
*>What this really the catalyst for the current Perl 6 development?
Well...calling it a catalyst may be too dramatic a word. The meeting was
originally a gathering of Chip Salzenberg, Jarkko Hietaniemi, myself, Tim
Bunce, Sarathy, Nick Ing-Simmons, Larry Wall, Nat Torkington, brian d foy
and Adam Turoff, brougt together to draft a constitution of sorts since
the community seemed to be fragmenting. Jon showed up to the meeting late
and found us talking about the community and started throwing things to
express his discontent with how perl itself was stagnating, possibly even
dying, and that we should be talking about reviving Perl. The cup incident
was planned theatre from what I was told later. So, it was already a fait
accompli but the tantrum was it's outing.
*>How many mugs were broken?
only one. 5 were thrown but they were tough :)
*>Were they coffee mugs or coffee cups?
Coffee mugs. Standard hotel issue.
*>What colour were they?
White.
*>Did anyone keep some broken cups for later display in musuem?
No :)
*>Did anyone photograph the incident or broken cups?
No :) Thank goodness as I'd hate to have a photo of me diving under the
table.
Our experiments use some web services written in Perl (DocDB). The great thing compared to python is they they work for years untouched, through many system updates. Stuff written in Python bitrots fast (using MoinMoin for a wiki was a terrible idea, in retrospect...)
I am not old enough to have learned perl but not young enough to not know some perl and its problems.
But the article or at least the title would be much more suitable if perl is replaced by "CUDA". You can't be working with that and be arrogant, because even self centric people would suffer enough pain not to change. And if perl makes you feel it is made by humans. Then "CUDA" sure would feel like something that came straight from the hell.
Note: I understand that the article is more about talking about perl and remind people that it existed and was famous language one day. But I couldn't resist the temptation of the title.
I write Perl, too, and I love it. I have comments, especially next to the regexes, but honestly, I think my code is readable and maintainable because I went back to it a year later and I still understand everything.
I still use it in my job every day too. It's just become a meme, the whole "write-only language" thing. No one says that about shell scripting, despite the sigils and plenty of stuff that becomes incomprehensible to almost anyone if you do anything very complicated. I'd much rather diagnose some newbie's Perl script than some of the commercially-distributed bash installers I've had to deal with.
I took great pride in making readable, maintainable perl.
I worked at a VFX place that was held together by loads of perl, written over a good 15 years. Some of it was clever, but most of it was plain readable scripts.
The key to keeping it readable was decent code reviews and someone ripping the piss out of you for making unreadable soup.
Its all python nowadays, I do miss CPAN, but I don't miss perls halfarsed function args.
However for the longest time, the documentation for perl was >> than python. At the time python doc were written almost exclusively for people who knew how to python. Perl docs assumed you were in a hurry and needed an answer now, and if you were still reading by the end assumed you either cared or were lost and needed more info.
With the rise of datascience, python has lost its "oh you should be able to just guess, look how _logical_ the syntax is" to "do it like this."
> I took great pride in making readable, maintainable perl.
In the past when I used perl, I did the same thing.
But I came to learn one thing about perl - its good point is its bad point.
When I used it, perl was the highest level language I ever used. It was expressive, meaning I could take an idea in my head, and implement it in perl with the least friction of any language.
When I worked with other people's perl, I found they were mindful and cared about what they were doing.
But the way they thought was sometimes almost alien to me, so the expression of their thinking was a completely different type of perl, and it was lots less readable to me. And frequently the philosophy of what they wrote was backwards or inside out from what I would do.
Now I have replaced perl with python day to day and although implementation of code seems a few steps removed from my thinking, it seems that other people's code is more easily read and understood. (this is just my opinion)
> perlcritic is a Perl source code analyzer. It is the executable front-end to the Perl::Critic engine, which attempts to identify awkward, hard to read, error-prone, or unconventional constructs in your code. Most of the rules are based on Damian Conway's book Perl Best Practices. However, perlcritic is not limited to enforcing PBP, and it will even support rules that contradict Conway. All rules can easily be configured or disabled to your liking.
It helped me a lot. I think every Perl developers should use it, might help to avoid headache later on. Be careful with severity level "brutal" and "cruel" and "harsh", however. I think "gentle" works in many cases. That said, I used "brutal" and I only fixed the legitimate issues. "brutal" helped me write a proper POD, for one, as "gentle" does not complain about that.
Perl’s function arguments no longer require you to shift or to access the @_ array. There are even proper argument signatures now. There’s also continuing improvements in putting a one true way to do objects into the core language, so you don’t have to bless a hash, use Moose, or Moo, or use Object::InsideOut (or any of a dozen other non-core modules).
Mention of Perl will always reminds me of that time I put Perl in a PR at a Ruby shop. It was a beautiful, portable little piece of code that they made me take outside and shoot in the back of the head. Fair enough, but I will never get over it lol. I don’t even write Perl scripts for personal work anymore, I use python (only because uv makes it not awful), but it’s not about that!
Leaving aside issues of language design and the emergence of other languages, it's interesting to think about other reasons why Perl lost popularity. Some of you know this history better than I do, but I think that it's now unknown to most HN readers.
The enormous reason that I see is the insistence, from Larry Wall and others, on a bottom-up "community" transition from Perl 5 to Perl 6. The design process for Perl 6 was announced at a Perl conference in 2000 [1]; 15 years later, almost every Perl user was still using Perl 5. The inability of the Perl community to push forward collectively in a timely way should be taken by every other language community as a cautionary tale.
Tim O'Reilly made a secondary point that may also be important. For a long time, Perl books were O'Reilly's biggest sellers. But the authors of those titles didn't act on his suggestion that they write a "Perl for the Web" book (really a Perl-for-CGI book). Books like that eventually came, but the refusal of leading authors to write such a book may have made it easier for PHP to get a foothold.
I think Perl died from a combination of three factors:
1. The rise of other web languages that did what Perl was good at but better.
Perl was probably a fine language for sysadmins doing some text munging. Then it became one of the first languages of the web thanks to Apache and mod_perl, but it was arguably never great at that. Once PHP, Python, Ruby, and (eventually) JavaScript showed up, Perl's significant deficiencies for large maintainable codebases made it very hard to compete.
In many cases, a new, better language can't outcompete an old entrenched one. The old language has an ecosystem and users really don't like rewriting programs, so that gives it a significant competitive advantage.
But during the early rise of the web, there was so much new code being written that that advantage evoporated. During the dot com boom, there were thousands of startups and millions of lines of brand new code being written. In that rare greenfield environment, newer languages had a more even playing field.
2. Perl 6 leaving its users behind.
As a language maintainer, I feel in my bones how intense the desire is to break with the past and Do Things Right This Time. And I'm maintaining a language (Dart) that is relatively new and wart-free compared to Perl. So I can't entirely blame Wall for treating Perl 6 as a blank check to try out every new idea under the sun.
But the problem is that the more changes you make to the language, the farther you pull away from your users and their programs. If they can't stay with you, you both die. They lose an active maintainer for the core tools they rely on. And you lose all of their labor building and maintaining the ecosystem of packages everyone relies on.
A racecar might go a lot faster if it jettisons all the weight of its fuel tank, but it's not going to faster for long.
I think the Perl 6 / Raku folks go so excited to make a new language that they forgot to bring their users with them. They ran ahead and left them behind.
3. A wildly dynamic language.
If you want to evolve a language and keep the ecosystem with you while you do it, then all of that code needs to be constantly migrated to the new language's syntax and semantics. Hand-migrating is nightmarishly costly. Look at Python 3.
It's much more tractable if you can do most of that migration automatically using tools. In order to do that, the tools need to be able to reason in detail about the semantics of a program just using static analysis. You can't rely on dynamic analysis (i.e. running the code and seeing what it does) because it's just not thorough enough to be safe to rely on for large-scale changes to source code.
Obviously, static types help a lot there. Perl 5 not only doesn't have those, but you can't even parse a Perl program without running Perl code. It is a fiendishly hard language to statically analyze and understand the semantics of.
So even if the Perl 6 folks wanted to bring the Perl 5 ecosystem with them, doing so would have been extremely challenging.
I would say this is a case study in a programming language tragedy, but I honestly don't even know if it's a bad thing. It may be that programming languages should have a life cycle that ends in them eventually being replaced entirely by different languages. Perhaps Perl's time had simply come.
I am grateful for all of the innovative work folks have done on Perl 6 and Raku. It's a cornucopia of interesting programming language ideas that other languages will be nibbling on for decades.
I had lots of experience writing Perl5 before the company switched to Python3.
> The inability of the Perl community to push forward collectively in a timely way should be taken by every other language community as a cautionary tale.
I think this is a good point that I hadn't considered before.
I think Perl stopped being able to attract new users. There is always going to be users leaving. If they aren't replaced, you will slowly shrink.
I think the point you raised is part of why they couldn't attract new users. I also think people asked themselves "why chose perl now, if I know I need to re-write when Perl6 comes?" and decided Perl5 was bad choice. I also think the fact Perl had this reputation for being ugly, difficult, and "write only line noise" kept people from even considering it, even if that reputation didn't match production codebases.
Perl was the perfect language when the majority of people wanting to use it already knew shell, sed, awk, and C.
It succeeded because it was a beautiful and horrible combination of those tools/languages. If you know those things, Perl is really easy to bang together and generate a webpage or use to automate administrative task.
Given Larry Wall's education, perhaps we shouldn't be surprised that Perl underwent a linguistic evolution from pidgin[1] to creole[2].
I came to Perl a bit late, not being a super adept user of Unix and only having written C in school. I'd put myself in the category of Perl developer that was part of the second "creole language" phase of Perl's development. I learned a ton of Unix and got better at C by learning Perl.
While Perl's mixed nature made it successful, when the world of web development expanded to include more people without the necessary background to benefit from the admixture, it went from asset to hinderance. All that syntax went from instantly familiar to bizarre. A perfect example of this are the file test operators[3].
The Perl 6 struggles definitely added to the difficulties posed by the changing nature of the web dev community. They created enough uncertainty that tons of people asked themselves "Why should I learn Perl 5 when Perl 6 is just around the corner?". That slowed adoption from in the 2001-2010 timeframe while Python and Ruby grew rapidly.
Rakulang is kind of magical. Writing it is like using a language given to us by aliens. I wish it was getting more uptake because it is fun and truly mind expanding to write.
In the end, I think the shifting nature of the community was a larger factor in the decline of Perl than the slow Perl 6 rollout and failure of messaging around it.
I still love writing Perl 5 and I wish I got to do more of it.
One thing I wish other languages had was Perl's taint mode: Once enabled, input coming from the outside was "tainted", along with anything you explicitly marked as tainted. If a tainted variable was used to populate another tainted variable (such as by concatenation), the result itself was tainted. If a tainted variable was used in certain ways (such as with the `open` call), the program crashed. The primary way to remove a taint was by running the variable through a regular expression, and using the captured matches (which would not be tainted).
I write some new Perl/Gtk application a couple times a year. And I use it for automating basic things almost daily. I bet lots of people chose to write in perl for personal projects. It just isn't very visible.
But not that many. And that's why Perl is still Perl. Popularity brings change which means old code stops working.
Perl code from the year 2000 still works in a perl interpreter+libs today. And perl code written today still works on perl interpreter+libs from the year 2000. That incredible stability and reliability is what makes it great. Write something then use it 20 years later and everything just works anywhere you try to run it.
Perl sigils are horrible; perl magical variables are horrible, perl lack of sane object and argument passing is horrible. (Moose was improvement but slow, if I remember well.) It's a language of cludges on top of other cludges.
I guess it became popular because it existed and there was nothing better (nobody will write in awk if not pressed to).
We don't need badly designed tools to stay humble. There is enough cognitive load from all the bad programmers (and now LLMs spewing slop), no need to add another nonsense.
I admit though that writing perl makes you feel "clever" - "huh that's a funny shortcut I didn't know! Writing $\<>^^ will give me name of last used file on blue moon on thursday!" but... uh.
> I admit though that writing perl makes you feel "clever" - "huh that's a funny shortcut I didn't know! Writing $\<>^^ will give me name of last used file on blue moon on thursday!" but... uh.
I write Perl and I hate this mindset a lot. A LOT. Some people get excited and feel like they are megawizards of the White Council because they can line up all their sigils and make them dance, and thus feel just that little bit superior. There's nothing superior about maintaining a program where to change it, you need to solve puzzles three, make the change, and wrap it in another puzzle for the next guy.
I know that feeling of being a wizard, and I used to have that smug expression on my face, too. But now I'm over 40, and I'm jumping from one place to another in a magical codebase to debug it, and I can't help but feel like if it was just that little bit less magical, I could have fixed it and be done with it quite a while ago already.
A lot of people in this thread speculate that Raku (formerly "Perl 6") killed Perl. But I have yet to see convincing first hand accounts confirming that.
I certainly don't believe it. Everyone I talked to at the time who worked with Perl knew it would not go away: humanity had chained too much of the infrastructure of the internet to it. Someone would have to maintain it for many years to come, even if Larry's new experiment became a wild success. (Already back then people seemed skeptical of the experiment and hung back with Perl 5 waiting to see what came out of it before paying too much attention.)
I still struggle to understand why Perl went out of favour[1] but I think what another commenter wrote here might come close: for Unixy folks who know shell, C, awk, sed, Vim, etc. Perl is a natural extension. Then came a generation of programmers brought up on ... I don't know, Visual Basic and Java? and these were more attracted to something like Python, which then became popular enough to become the next generation's first language.
The first thing I think of when thinking of Perl is anything but humble, not because Perl monks aren’t humble, they certainly are, they even inspired rubys we are humble cause hi is humble I suppose :D but like I said elsewhere Perl is like nineties music its simply the best, so in my eyes Perl programmers are (unix) greybeards and the most expert you can imagine, so don’t think they could be as humble cause the level of the competency could allow quite some hubris. :D
Anyway this is the analogy I see with programming languages and Linux distros,
Slackware was created for lisp and its KISS principle later manifested in clojure. Early Debian was released with same Perl versions as the learning Perl book. And both have heavy emphasis on reproducibility and testing. And redhats and ibms other business is Java and redhats ceo even went to work on unity a mono fork or something.
So you Perl came from Unix but it shaped Linux and by extension floss world pretty much.
It’s like an elder who knows all the answers but nobody asks.
Edit: ah and yes Larry was right about timtoady indeed, it can be Perl or Python or whatever :D
I remember reading the Perl O'Reilly book (Introduction to Perl[0]) end-to-end and basically feeling that it all makes sense - ($)calar, (@)rray and % for dictionary (because we have a pair of "o"s representing key/value) and so on. Coming from only writing bash (which is all people around me wrote), it was like a becoming a superhero overnight. I rewrote all my bash scripts in Perl and got high level language features with blazing speed. I relished taking people's bash scripts that took an hour and rewriting them in Perl for them to take barely few minutes (which was objectively terrible performance but I was a novice programmer then and nobody else knew better). I was a hotshot. It was an awesome feeling.
Later I got another role solely because they couldn't find Perl programmers and I wasn't half bad at it. But this was an actual application written by a bunch of people who wanted to write clever code and it was like handing over the keys to a missile depot to a bunch of arsonists. Many thousands LoC. By the end of it, I was told that we need to move to using Java and I could barely contain my relief.
For one-off scripts, still nothing flows like Perl. It is the most interesting language I have coded in, bar none.
[0] correction: Learning Perl, the llama book (thanks @ninkendo)
66 comments
[ 3.2 ms ] story [ 74.2 ms ] threadI agree with the intention of the quote, sadly it didn't work out like that.
It was the first language I wrote professionally and I always thought it was a lot of fun, but if I want to be humbled these days I reach for Haskell (like a lot of the Perl community it sounds like...).
EDIT: okay I read the article, thanks to welpo for the archive link. Yeah this is kind of a nostalgic piece so I think my original comment is still relevant. I do like Perl still, I will always have a spot in my heart for it. I appreciate especially how seriously Larry Wall tried to think about approaching things vis-a-vis linguistics even if I don't necessarily think that's the best approach for a language used by an engineering team these days.
I hope it sticks around in any case. It is truly unique.
The two languages I enjoy the most are Perl and Lisp - and the majority of my non-work related coding is split between those two.
Unfortunately it doesn’t do automatic tail call elimination but that’s a tooling limitation more than a language limitation.
I'm not clear which way the author thinks this works but having started coding in the 90s I feel that with Perl you had to try to understand the quirks of language and the language didn't try to reach out to programmers to make things easy. Whereas other coding languages aim to be intuitive, with clearer syntax, more logical naming and frameworks to obscure complexity, which to my mind is a better way to bridge the gap between us and "the machines".
Perl
- Was an easy jump from bash to Perl
- Perl never felt like it "got in the way"
- was WAY too easy to write "write only code"
- that being said, I learned Java first and most people found MY Perl code to be very legible
- regexes as first class citizen were amazing
- backwards compatible is GREAT for older systems still running Perl (looking at you banks and some hedge funds)
Python
- Forced indentation made it MUCH easier to read other people's code
- everything is an object from day one was much better than "bless" in Perl
- no standard way of setting up an environment for MANY years hurt
- sklearn and being taught in universities were real game changers
I will say coming from years of perl that python had a refreshing amount of "batteries included" via the standard library.
It was only rarely that my code needed "outside help", usually something like requests or numpy.
I suspect this is because I used python in the same environment as perl, automating unixy kinds of things.
I suspect "setting up an environment" is because python has been so successful, becoming an enormously broad general language.
Ever tried to deal with 20-year-old duct tape?
>Partway through, Jon Orwant comes in, and stands there for a few minutes listening, and then he very calmly walks over to the coffee service table in the corner, and there were about 20 of us in the room, and he picks up a coffee mug and throws it against the other wall and he keeps throwing coffee mugs against the other wall, and he says "we are fucked unless we can come up with something that will excite the community, because everyone's getting bored and going off and doing other things".
https://en.wikibooks.org/wiki/Raku_Programming/Perl_History#...
Intermission: The Jon Orwant Mug-Throwing Incident in 2000
By 2000, it was evident that Perl needed an infusion of life:
"The [P5P / Perl Conference] meeting was originally a gathering of Chip Salzenberg, Jarkko Hietaniemi, Elaine Ashton, Tim Bunce, Sarathy, Nick Ing-Simmons, Larry Wall, Nat Torkington, brian d foy and Adam Turoff, brougt together to draft a constitution of sorts since the community seemed to be fragmenting. Jon showed up to the meeting late and found us talking about the community and started throwing things to express his discontent with how perl itself was stagnating, possibly even dying, and that we should be talking about reviving Perl. The cup incident was planned theatre from what I was told later. So, it was already a fait accompli but the tantrum was it's outing." [1]
https://www.nntp.perl.org/group/perl.packrats/2002/07/msg3.h...
Andrew.Savige@ir.com [Andrew.Savige@ir.com] quoth:
Well...calling it a catalyst may be too dramatic a word. The meeting was originally a gathering of Chip Salzenberg, Jarkko Hietaniemi, myself, Tim Bunce, Sarathy, Nick Ing-Simmons, Larry Wall, Nat Torkington, brian d foy and Adam Turoff, brougt together to draft a constitution of sorts since the community seemed to be fragmenting. Jon showed up to the meeting late and found us talking about the community and started throwing things to express his discontent with how perl itself was stagnating, possibly even dying, and that we should be talking about reviving Perl. The cup incident was planned theatre from what I was told later. So, it was already a fait accompli but the tantrum was it's outing. only one. 5 were thrown but they were tough :) Coffee mugs. Standard hotel issue. White. No :) No :) Thank goodness as I'd hate to have a photo of me diving under the table.https://web.archive.org/web/20110716115800/http://www.spider... is about as close to a photo of this as you'll find :)
e.
Rust
I'd say Perl is the fruit of the marriage between shell and Lisp.
But the article or at least the title would be much more suitable if perl is replaced by "CUDA". You can't be working with that and be arrogant, because even self centric people would suffer enough pain not to change. And if perl makes you feel it is made by humans. Then "CUDA" sure would feel like something that came straight from the hell.
Note: I understand that the article is more about talking about perl and remind people that it existed and was famous language one day. But I couldn't resist the temptation of the title.
There's no humility in the list.
(re nobody codes in Perl: I still do professionally, and I'll probably never understand why it draws so much hate)
I worked at a VFX place that was held together by loads of perl, written over a good 15 years. Some of it was clever, but most of it was plain readable scripts.
The key to keeping it readable was decent code reviews and someone ripping the piss out of you for making unreadable soup.
Its all python nowadays, I do miss CPAN, but I don't miss perls halfarsed function args.
However for the longest time, the documentation for perl was >> than python. At the time python doc were written almost exclusively for people who knew how to python. Perl docs assumed you were in a hurry and needed an answer now, and if you were still reading by the end assumed you either cared or were lost and needed more info.
With the rise of datascience, python has lost its "oh you should be able to just guess, look how _logical_ the syntax is" to "do it like this."
At some point when the LLM fails, you'll need a real programmer to figure it out.
But IMO, LLMs are code generation, and code generation always fails at some point when the pile of generated code topples, no matter the language.
The amount of bad enterprise LLM code that will be cranked out in the next few years is going to be fascinating to watch.
In the past when I used perl, I did the same thing.
But I came to learn one thing about perl - its good point is its bad point.
When I used it, perl was the highest level language I ever used. It was expressive, meaning I could take an idea in my head, and implement it in perl with the least friction of any language.
When I worked with other people's perl, I found they were mindful and cared about what they were doing.
But the way they thought was sometimes almost alien to me, so the expression of their thinking was a completely different type of perl, and it was lots less readable to me. And frequently the philosophy of what they wrote was backwards or inside out from what I would do.
Now I have replaced perl with python day to day and although implementation of code seems a few steps removed from my thinking, it seems that other people's code is more easily read and understood. (this is just my opinion)
> perlcritic is a Perl source code analyzer. It is the executable front-end to the Perl::Critic engine, which attempts to identify awkward, hard to read, error-prone, or unconventional constructs in your code. Most of the rules are based on Damian Conway's book Perl Best Practices. However, perlcritic is not limited to enforcing PBP, and it will even support rules that contradict Conway. All rules can easily be configured or disabled to your liking.
https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic
It helped me a lot. I think every Perl developers should use it, might help to avoid headache later on. Be careful with severity level "brutal" and "cruel" and "harsh", however. I think "gentle" works in many cases. That said, I used "brutal" and I only fixed the legitimate issues. "brutal" helped me write a proper POD, for one, as "gentle" does not complain about that.
You mean you don't like writing things like...
All that old code still works, though.
The enormous reason that I see is the insistence, from Larry Wall and others, on a bottom-up "community" transition from Perl 5 to Perl 6. The design process for Perl 6 was announced at a Perl conference in 2000 [1]; 15 years later, almost every Perl user was still using Perl 5. The inability of the Perl community to push forward collectively in a timely way should be taken by every other language community as a cautionary tale.
Tim O'Reilly made a secondary point that may also be important. For a long time, Perl books were O'Reilly's biggest sellers. But the authors of those titles didn't act on his suggestion that they write a "Perl for the Web" book (really a Perl-for-CGI book). Books like that eventually came, but the refusal of leading authors to write such a book may have made it easier for PHP to get a foothold.
[1] https://en.wikipedia.org/wiki/Raku_(programming_language)#Hi...
1. The rise of other web languages that did what Perl was good at but better.
Perl was probably a fine language for sysadmins doing some text munging. Then it became one of the first languages of the web thanks to Apache and mod_perl, but it was arguably never great at that. Once PHP, Python, Ruby, and (eventually) JavaScript showed up, Perl's significant deficiencies for large maintainable codebases made it very hard to compete.
In many cases, a new, better language can't outcompete an old entrenched one. The old language has an ecosystem and users really don't like rewriting programs, so that gives it a significant competitive advantage.
But during the early rise of the web, there was so much new code being written that that advantage evoporated. During the dot com boom, there were thousands of startups and millions of lines of brand new code being written. In that rare greenfield environment, newer languages had a more even playing field.
2. Perl 6 leaving its users behind.
As a language maintainer, I feel in my bones how intense the desire is to break with the past and Do Things Right This Time. And I'm maintaining a language (Dart) that is relatively new and wart-free compared to Perl. So I can't entirely blame Wall for treating Perl 6 as a blank check to try out every new idea under the sun.
But the problem is that the more changes you make to the language, the farther you pull away from your users and their programs. If they can't stay with you, you both die. They lose an active maintainer for the core tools they rely on. And you lose all of their labor building and maintaining the ecosystem of packages everyone relies on.
A racecar might go a lot faster if it jettisons all the weight of its fuel tank, but it's not going to faster for long.
I think the Perl 6 / Raku folks go so excited to make a new language that they forgot to bring their users with them. They ran ahead and left them behind.
3. A wildly dynamic language.
If you want to evolve a language and keep the ecosystem with you while you do it, then all of that code needs to be constantly migrated to the new language's syntax and semantics. Hand-migrating is nightmarishly costly. Look at Python 3.
It's much more tractable if you can do most of that migration automatically using tools. In order to do that, the tools need to be able to reason in detail about the semantics of a program just using static analysis. You can't rely on dynamic analysis (i.e. running the code and seeing what it does) because it's just not thorough enough to be safe to rely on for large-scale changes to source code.
Obviously, static types help a lot there. Perl 5 not only doesn't have those, but you can't even parse a Perl program without running Perl code. It is a fiendishly hard language to statically analyze and understand the semantics of.
So even if the Perl 6 folks wanted to bring the Perl 5 ecosystem with them, doing so would have been extremely challenging.
I would say this is a case study in a programming language tragedy, but I honestly don't even know if it's a bad thing. It may be that programming languages should have a life cycle that ends in them eventually being replaced entirely by different languages. Perhaps Perl's time had simply come.
I am grateful for all of the innovative work folks have done on Perl 6 and Raku. It's a cornucopia of interesting programming language ideas that other languages will be nibbling on for decades.
> The inability of the Perl community to push forward collectively in a timely way should be taken by every other language community as a cautionary tale.
I think this is a good point that I hadn't considered before.
I think Perl stopped being able to attract new users. There is always going to be users leaving. If they aren't replaced, you will slowly shrink.
I think the point you raised is part of why they couldn't attract new users. I also think people asked themselves "why chose perl now, if I know I need to re-write when Perl6 comes?" and decided Perl5 was bad choice. I also think the fact Perl had this reputation for being ugly, difficult, and "write only line noise" kept people from even considering it, even if that reputation didn't match production codebases.
It succeeded because it was a beautiful and horrible combination of those tools/languages. If you know those things, Perl is really easy to bang together and generate a webpage or use to automate administrative task.
Given Larry Wall's education, perhaps we shouldn't be surprised that Perl underwent a linguistic evolution from pidgin[1] to creole[2].
I came to Perl a bit late, not being a super adept user of Unix and only having written C in school. I'd put myself in the category of Perl developer that was part of the second "creole language" phase of Perl's development. I learned a ton of Unix and got better at C by learning Perl.
While Perl's mixed nature made it successful, when the world of web development expanded to include more people without the necessary background to benefit from the admixture, it went from asset to hinderance. All that syntax went from instantly familiar to bizarre. A perfect example of this are the file test operators[3].
The Perl 6 struggles definitely added to the difficulties posed by the changing nature of the web dev community. They created enough uncertainty that tons of people asked themselves "Why should I learn Perl 5 when Perl 6 is just around the corner?". That slowed adoption from in the 2001-2010 timeframe while Python and Ruby grew rapidly.
Rakulang is kind of magical. Writing it is like using a language given to us by aliens. I wish it was getting more uptake because it is fun and truly mind expanding to write.
In the end, I think the shifting nature of the community was a larger factor in the decline of Perl than the slow Perl 6 rollout and failure of messaging around it.
I still love writing Perl 5 and I wish I got to do more of it.
[1] https://en.wikipedia.org/wiki/Pidgin [2] https://en.wikipedia.org/wiki/Creole_language [3] https://perldoc.perl.org/functions/-X
ps: ah well, that was fast https://en.wikipedia.org/wiki/Taint_checking#History :) (1989)
But not that many. And that's why Perl is still Perl. Popularity brings change which means old code stops working.
Perl code from the year 2000 still works in a perl interpreter+libs today. And perl code written today still works on perl interpreter+libs from the year 2000. That incredible stability and reliability is what makes it great. Write something then use it 20 years later and everything just works anywhere you try to run it.
That's why I chose Perl.
I guess it became popular because it existed and there was nothing better (nobody will write in awk if not pressed to).
We don't need badly designed tools to stay humble. There is enough cognitive load from all the bad programmers (and now LLMs spewing slop), no need to add another nonsense.
I admit though that writing perl makes you feel "clever" - "huh that's a funny shortcut I didn't know! Writing $\<>^^ will give me name of last used file on blue moon on thursday!" but... uh.
I write Perl and I hate this mindset a lot. A LOT. Some people get excited and feel like they are megawizards of the White Council because they can line up all their sigils and make them dance, and thus feel just that little bit superior. There's nothing superior about maintaining a program where to change it, you need to solve puzzles three, make the change, and wrap it in another puzzle for the next guy.
I know that feeling of being a wizard, and I used to have that smug expression on my face, too. But now I'm over 40, and I'm jumping from one place to another in a magical codebase to debug it, and I can't help but feel like if it was just that little bit less magical, I could have fixed it and be done with it quite a while ago already.
I certainly don't believe it. Everyone I talked to at the time who worked with Perl knew it would not go away: humanity had chained too much of the infrastructure of the internet to it. Someone would have to maintain it for many years to come, even if Larry's new experiment became a wild success. (Already back then people seemed skeptical of the experiment and hung back with Perl 5 waiting to see what came out of it before paying too much attention.)
I still struggle to understand why Perl went out of favour[1] but I think what another commenter wrote here might come close: for Unixy folks who know shell, C, awk, sed, Vim, etc. Perl is a natural extension. Then came a generation of programmers brought up on ... I don't know, Visual Basic and Java? and these were more attracted to something like Python, which then became popular enough to become the next generation's first language.
[1]: As someone who knows me might understand: https://entropicthoughts.com/why-perl
Later I got another role solely because they couldn't find Perl programmers and I wasn't half bad at it. But this was an actual application written by a bunch of people who wanted to write clever code and it was like handing over the keys to a missile depot to a bunch of arsonists. Many thousands LoC. By the end of it, I was told that we need to move to using Java and I could barely contain my relief.
For one-off scripts, still nothing flows like Perl. It is the most interesting language I have coded in, bar none.
[0] correction: Learning Perl, the llama book (thanks @ninkendo)