6 ms·

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

by mmastrac 11mo ago

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

frankwiles 11mo ago
Yeah I think I would have been considered part of the “in” crowd of Perl to some degree and it wasn’t the culture that drove me away and to Python. It was Django and the people involved with it.
- liveoneggs 11mo ago
  > and the people involved with it. Culture?
MangoToupe 11mo ago
Perl was (and still is) a very expressive and concise language for working with text and a unix-style system. It exists in the odd space between a shell language and a general purpose language. But, shell scripting has already become somewhat of an arcane skill. I think the article nailed that Perl was just too hard to learn for the value it provided to survive. Python is not nearly as, erm, expressive as perl for working in that space, but it is much easier to learn, both in terms of reading and writing. In other words, it encourages broadly maintainable code. Ruby is quite similar (although I think people massively overstate how much the language itself generally encourages understandable semantics)
- zihotki 11mo ago
  > Perl was (and still is) a very expressive and concise language And that could be one of major reasons why it lost in popularity. It was and still is easy to write but hard to read.
- jordanb 11mo ago
  Shell is a crappy scripting language because it has primitive data structures and data flow control making it hard to manage and manipulate data as you process it between applications. The fact that newlines are such a problem is a case in point. Python is a crappy shell scripting language because the syntax around pipe and subprocess is really clunky. Perl managed to have decent data structures and also have decent syntax around subprocess calls. But I feel like the Python invoke module gives me everything I need wrt subprocess calls. I basically write any nontrivial "shell script" these days as a Python invoke command.
  - zahlman 11mo ago
    I assume you refer to https://www.pyinvoke.org/ https://www.pyinvoke.org/ which I just looked up. It looks quite promising, thanks for the heads-up.
- zahlman 11mo ago
  > Perl was (and still is) a very expressive and concise language for working with text and a unix-style system. It exists in the odd space between a shell language and a general purpose language. GvR explicitly describes the motivation behind Python in similar terms (I can probably find a timestamp in that recent documentary for this). But the goal there was to be fully "general purpose" (and readable and pragmatic, more than artistic) while trying to capture what he saw as the good things about shell languages. And it's changed quite a bit since then, and there are many things I would say with the benefit of hindsight were clear missteps. We all joke about the hard problems of computer science, but it seems to me that the hard problems of programming language design, specifically (and perhaps software engineering more generally?) include having good taste and figuring out what to do about reverse compatibility. > I think the article nailed that Perl was just too hard to learn for the value it provided to survive. Python is not nearly as, erm, expressive as perl for working in that space, but it is much easier to learn The use cases have also changed over time. Quite a lot of developers ended up on Windows (although that pendulum is perhaps shifting again) where the rules and expectations of "shell" are very different. To say nothing of e.g. web development; long gone are the days of "cgi-bin" everywhere.
atherton94027 11mo ago
There was so much complexity hidden behind "do what I mean". For example, scalar vs array context which was super subtle: my @var = @array # copy the array my $var = @array # return the count of elements in array
- js2 11mo ago
  Or even worse: my($f) = `fortune`; # assigns first line of output to $f. my $f = `fortune`; # assign all output to $f. Which allegedly got a HS kid in hot water[^1]. [^1]: "It's all about context" (2001): https://archive.ph/IB2kR https://archive.ph/IB2kR (http://www.stonehenge.com/merlyn/UnixReview/col38.html http://www.stonehenge.com/merlyn/UnixReview/col38.html)
  - weare138 11mo ago
    Then don't use the low level interfaces. In Perl, language features are plug and play. Everything's in a module. Use the core module List::Util instead.
  - PunchyHamster 11mo ago
    I think what's most likely to happen here is that: * a developer that knew how it worked used it in code where he *wanted* to get the first line * someone just starting up copied it over and assumed that's the way to get the content of command into a variable It's essentially complaining about using feature wrong on purpose, because the person that made mistake never learned the language. my($var1, $var2...) is a way to multi-assign variables from an array. and that makes perfect sense when you look at it. Perl have no multiple returns, but if you need a function that returns 2 variables it is very easy to make it work with: my ($bandwidth, $latency) = speedtest($host) Perl's feature for returning different type depending on caller is definitely a confusing part but my @lines = `fortune` returning lines makes perfect sense for the use case (you call external commands to parse its output, and if you do that you generally want it in lines, because then you can just do foreach my $line (`fortune`) {} and it "just works". Now you might ask "why make such shortcuts?". Well, one of big mistakes when making Perl is that it was also aimed as replacement for sed/awk for the oneliners, so language is peppered with "clever short ways to do stuff", and it's a pleasure to use in quick ad-hoc oneliners for CLI.... but then people try to use same cleverness in the actual code and it ends up with the unreadable mess people know Perl for. the fact you can do my ($first_line, $second_line, ...) = `fortune` is just the feature being.... consistent in its use "when you give it array, it will fill it with lines from the executed command" you gave it array, and it just did what it does with arrays.
eduction 11mo ago
I agree and Steve Yegge covered the reasons well here: https://sites.google.com/site/steveyegge2/ancient-languages-perl https://sites.google.com/site/steveyegge2/ancient-languages-... His point about references is no small thing. Other dynamic languages don’t make users think much about the distinction between references and values at the syntax level. With Perl you needed to use “->” arrow operator frequently if and only if you were using references. So getting at a map inside an array or vice versa had its own syntax vs reading a string in a map or array. Also it had bolted on, awkward OO on top of the bolted on, awkward params passing. You literally had to shift “self” (or “this”) off a magical array variable (@_). By default it wouldn’t warn if you tried to read from an undeclared variable or tried to use one in a conditional or assign from one. You had to declare “use strict;” for that. Which wasn’t hard! But these awkward things piled up, a bunch of small cuts. Don’t forget “use warnings;” also, another thing to put at the top of every Perl file. To the extent its awkward syntax came out of aping of shell and common Unix cli tools, you could maybe see it as cultural issue if you squint. But any language in the mid 90s was infected with the “rtfm” priesthood vibe the author writes about, because the internet then was disproportionately populated by those sysop types, especially the part that can answer programming language questions on usenet, which is basically where you had to ask back then. So for example Rails won for technical reasons, it is much more concise with fewer footguns than its Perl equivalents. I was actively coding web stuff in Perl when it came along and early switched. It wasn’t a cultural thing, having choice in Perl was fine (and ruby has sadly never grown much culture outside Rails - it could really use some). It probably did help that it came along in the mid aughts by which time you could ask questions on the web instead of Usenet. And it used YouTube for that first rails demo. So ruby did end up with a less sysopy culture but that had more to do with the timing of its success than the success itself.
- dehrmann 11mo ago
  > bolted on, awkward params passing Shell had to do this because of shell reasons, like how you need spaces where you shouldn't. Perl post-dated C by over a decade, so there was no reason for goofy argument unpacking.
  - ojosilva 11mo ago
nine_k 11mo ago
Perl is a great language, the way Scala and Haskell are great: as openly experimental languages, they tried interesting, unorthodox approaches, with varied success. "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say. Perl is not that good a language though for practical purposes. The same way, a breadboard contraption is not what you want to ship as your hardware product, but without it, and the mistakes made and addressed while tinkering with it, the sleek consumer-grade PCB won't be possible to design.
- pavel_lishin 11mo ago
  > "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say. Perl lets every developer write Perl in their own idiosyncratic way. And every developer does. It makes for very un-fun times when I'm having to read a file that's been authored by ten developers over ten years, each of whom with varying opinions and skill levels. I guess in 2026, it'll be 11 developers writing it over 11 years. My sincere apologies to those who come after me, and my sincere fuck-you to those who came before me. :)
  - creer 11mo ago
    > in 2026, it'll be 11 developers writing it over 11 years. Perhaps too, a tool that's been around and in active maintenance for 11 years has been wildly successful.
    - pavel_lishin 11mo ago
      I wouldn't say "wildly". I would say that it's critical enough to the company's workings that they devote enough resources to it to keep it going, but not enough resources to consider re-writing it or re-factoring it to be easier to work on.
  - hinkley 11mo ago
    Something I only figured out in the ‘10s is that the main tax of code smells is during debugging. Debugging when taken to the level of art is less about sorting all of the possible causes for a problem by likelihood but by ease of validation. Things that are cheap to check should be checked first unless they are really unlikely. You change the numbers game from trying to make the biggest cleaving lines possible, to smaller bites that can be done rapidly (and perhaps more importantly, mentally cheaply). Code smells chum the waters. Because where there is smoke sometimes there is fire, and code smells often hide bugs. You get into Tony Hoare’s Turing award speech; either no bugs are obvious, or there are no obvious bugs. So I end up making the change easy and then making the easy change because we have more code each week so the existing code needs to be simpler if someone is going to continue to understand the entire thing. Perl doesn’t seem to have figured this out at all.
0xbadcafebee 11mo ago
> it was just not a good language compared to others I think this was one of those things people just repeated, rather than having concrete examples from experience. It's like people saying a Toyota Corolla is better than a Honda Civic. Is it really? Or are they really just two different forms of the same thing? They both get you to the grocery store, they're both very reliable, small cheap. Having a preference is not the same thing as one actually being superior to the other.
bsder 11mo ago
Exactly. Perl did regexes very well. It did basic hash tables okay. It did everything else poorly. Once languages came along that did okay regexes and good hash tables along with getting other stuff decent, Perl just got pushed aside.
m463 11mo ago
When I learned perl, I encountered a way to express myself more easily than any other language. For example, being able to say not only "if foo" but "unless bar" gave me a more fluid vocabulary to get things out of my head and into code. Thing is, it worked great for ME but when I started interacting with other people's perl code, it all broke down. One person would write it all on one line. Another would be extra verbose. Some would use all the idioms, others would be 10 levels of nested braces. Every person's brain expressed itself differently and it was much harder to find common ground. Eventually I left perl for python, which seemed to be more sane. It seemed pythonic was more of a thing and the code was more readable. Also, it had a large standard library and you didn't have to leave the language to solve just about any problem. It did require extra effort to write code, but the benefits were pretty obvious. A couple other sort of random points - perl 6 was delayed and that might have hurt the language. Just the same python 3 did come out, but the 2 to 3 changeover was a huge negative to the language.

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

frankwiles 11mo ago

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

liveoneggs 11mo ago
> and the people involved with it. Culture?

MangoToupe 11mo ago

Perl was (and still is) a very expressive and concise language for working with text and a unix-style system. It exists in the odd space between a shell language and a general purpose language. But, shell scripting has already become somewhat of an arcane skill. I think the article nailed that Perl was just too hard to learn for the value it provided to survive. Python is not nearly as, erm, expressive as perl for working in that space, but it is much easier to learn, both in terms of reading and writing. In other words, it encourages broadly maintainable code. Ruby is quite similar (although I think people massively overstate how much the language itself generally encourages understandable semantics)

zihotki 11mo ago
> Perl was (and still is) a very expressive and concise language And that could be one of major reasons why it lost in popularity. It was and still is easy to write but hard to read.
jordanb 11mo ago
Shell is a crappy scripting language because it has primitive data structures and data flow control making it hard to manage and manipulate data as you process it between applications. The fact that newlines are such a problem is a case in point. Python is a crappy shell scripting language because the syntax around pipe and subprocess is really clunky. Perl managed to have decent data structures and also have decent syntax around subprocess calls. But I feel like the Python invoke module gives me everything I need wrt subprocess calls. I basically write any nontrivial "shell script" these days as a Python invoke command.
- zahlman 11mo ago
  I assume you refer to https://www.pyinvoke.org/ https://www.pyinvoke.org/ which I just looked up. It looks quite promising, thanks for the heads-up.
zahlman 11mo ago
> Perl was (and still is) a very expressive and concise language for working with text and a unix-style system. It exists in the odd space between a shell language and a general purpose language. GvR explicitly describes the motivation behind Python in similar terms (I can probably find a timestamp in that recent documentary for this). But the goal there was to be fully "general purpose" (and readable and pragmatic, more than artistic) while trying to capture what he saw as the good things about shell languages. And it's changed quite a bit since then, and there are many things I would say with the benefit of hindsight were clear missteps. We all joke about the hard problems of computer science, but it seems to me that the hard problems of programming language design, specifically (and perhaps software engineering more generally?) include having good taste and figuring out what to do about reverse compatibility. > I think the article nailed that Perl was just too hard to learn for the value it provided to survive. Python is not nearly as, erm, expressive as perl for working in that space, but it is much easier to learn The use cases have also changed over time. Quite a lot of developers ended up on Windows (although that pendulum is perhaps shifting again) where the rules and expectations of "shell" are very different. To say nothing of e.g. web development; long gone are the days of "cgi-bin" everywhere.

atherton94027 11mo ago

There was so much complexity hidden behind "do what I mean". For example, scalar vs array context which was super subtle: my @var = @array # copy the array my $var = @array # return the count of elements in array

js2 11mo ago
Or even worse: my($f) = `fortune`; # assigns first line of output to $f. my $f = `fortune`; # assign all output to $f. Which allegedly got a HS kid in hot water[^1]. [^1]: "It's all about context" (2001): https://archive.ph/IB2kR https://archive.ph/IB2kR (http://www.stonehenge.com/merlyn/UnixReview/col38.html http://www.stonehenge.com/merlyn/UnixReview/col38.html)
- weare138 11mo ago
  Then don't use the low level interfaces. In Perl, language features are plug and play. Everything's in a module. Use the core module List::Util instead.
- PunchyHamster 11mo ago
  I think what's most likely to happen here is that: * a developer that knew how it worked used it in code where he *wanted* to get the first line * someone just starting up copied it over and assumed that's the way to get the content of command into a variable It's essentially complaining about using feature wrong on purpose, because the person that made mistake never learned the language. my($var1, $var2...) is a way to multi-assign variables from an array. and that makes perfect sense when you look at it. Perl have no multiple returns, but if you need a function that returns 2 variables it is very easy to make it work with: my ($bandwidth, $latency) = speedtest($host) Perl's feature for returning different type depending on caller is definitely a confusing part but my @lines = `fortune` returning lines makes perfect sense for the use case (you call external commands to parse its output, and if you do that you generally want it in lines, because then you can just do foreach my $line (`fortune`) {} and it "just works". Now you might ask "why make such shortcuts?". Well, one of big mistakes when making Perl is that it was also aimed as replacement for sed/awk for the oneliners, so language is peppered with "clever short ways to do stuff", and it's a pleasure to use in quick ad-hoc oneliners for CLI.... but then people try to use same cleverness in the actual code and it ends up with the unreadable mess people know Perl for. the fact you can do my ($first_line, $second_line, ...) = `fortune` is just the feature being.... consistent in its use "when you give it array, it will fill it with lines from the executed command" you gave it array, and it just did what it does with arrays.

eduction 11mo ago

I agree and Steve Yegge covered the reasons well here: https://sites.google.com/site/steveyegge2/ancient-languages-perl https://sites.google.com/site/steveyegge2/ancient-languages-... His point about references is no small thing. Other dynamic languages don’t make users think much about the distinction between references and values at the syntax level. With Perl you needed to use “->” arrow operator frequently if and only if you were using references. So getting at a map inside an array or vice versa had its own syntax vs reading a string in a map or array. Also it had bolted on, awkward OO on top of the bolted on, awkward params passing. You literally had to shift “self” (or “this”) off a magical array variable (@_). By default it wouldn’t warn if you tried to read from an undeclared variable or tried to use one in a conditional or assign from one. You had to declare “use strict;” for that. Which wasn’t hard! But these awkward things piled up, a bunch of small cuts. Don’t forget “use warnings;” also, another thing to put at the top of every Perl file. To the extent its awkward syntax came out of aping of shell and common Unix cli tools, you could maybe see it as cultural issue if you squint. But any language in the mid 90s was infected with the “rtfm” priesthood vibe the author writes about, because the internet then was disproportionately populated by those sysop types, especially the part that can answer programming language questions on usenet, which is basically where you had to ask back then. So for example Rails won for technical reasons, it is much more concise with fewer footguns than its Perl equivalents. I was actively coding web stuff in Perl when it came along and early switched. It wasn’t a cultural thing, having choice in Perl was fine (and ruby has sadly never grown much culture outside Rails - it could really use some). It probably did help that it came along in the mid aughts by which time you could ask questions on the web instead of Usenet. And it used YouTube for that first rails demo. So ruby did end up with a less sysopy culture but that had more to do with the timing of its success than the success itself.

dehrmann 11mo ago
> bolted on, awkward params passing Shell had to do this because of shell reasons, like how you need spaces where you shouldn't. Perl post-dated C by over a decade, so there was no reason for goofy argument unpacking.
- ojosilva 11mo ago

nine_k 11mo ago

Perl is a great language, the way Scala and Haskell are great: as openly experimental languages, they tried interesting, unorthodox approaches, with varied success. "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say. Perl is not that good a language though for practical purposes. The same way, a breadboard contraption is not what you want to ship as your hardware product, but without it, and the mistakes made and addressed while tinkering with it, the sleek consumer-grade PCB won't be possible to design.

pavel_lishin 11mo ago
> "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say. Perl lets every developer write Perl in their own idiosyncratic way. And every developer does. It makes for very un-fun times when I'm having to read a file that's been authored by ten developers over ten years, each of whom with varying opinions and skill levels. I guess in 2026, it'll be 11 developers writing it over 11 years. My sincere apologies to those who come after me, and my sincere fuck-you to those who came before me. :)
- creer 11mo ago
  > in 2026, it'll be 11 developers writing it over 11 years. Perhaps too, a tool that's been around and in active maintenance for 11 years has been wildly successful.
  - pavel_lishin 11mo ago
    I wouldn't say "wildly". I would say that it's critical enough to the company's workings that they devote enough resources to it to keep it going, but not enough resources to consider re-writing it or re-factoring it to be easier to work on.
- hinkley 11mo ago
  Something I only figured out in the ‘10s is that the main tax of code smells is during debugging. Debugging when taken to the level of art is less about sorting all of the possible causes for a problem by likelihood but by ease of validation. Things that are cheap to check should be checked first unless they are really unlikely. You change the numbers game from trying to make the biggest cleaving lines possible, to smaller bites that can be done rapidly (and perhaps more importantly, mentally cheaply). Code smells chum the waters. Because where there is smoke sometimes there is fire, and code smells often hide bugs. You get into Tony Hoare’s Turing award speech; either no bugs are obvious, or there are no obvious bugs. So I end up making the change easy and then making the easy change because we have more code each week so the existing code needs to be simpler if someone is going to continue to understand the entire thing. Perl doesn’t seem to have figured this out at all.

0xbadcafebee 11mo ago

> it was just not a good language compared to others I think this was one of those things people just repeated, rather than having concrete examples from experience. It's like people saying a Toyota Corolla is better than a Honda Civic. Is it really? Or are they really just two different forms of the same thing? They both get you to the grocery store, they're both very reliable, small cheap. Having a preference is not the same thing as one actually being superior to the other.

bsder 11mo ago

Exactly. Perl did regexes very well. It did basic hash tables okay. It did everything else poorly. Once languages came along that did okay regexes and good hash tables along with getting other stuff decent, Perl just got pushed aside.

m463 11mo ago

When I learned perl, I encountered a way to express myself more easily than any other language. For example, being able to say not only "if foo" but "unless bar" gave me a more fluid vocabulary to get things out of my head and into code. Thing is, it worked great for ME but when I started interacting with other people's perl code, it all broke down. One person would write it all on one line. Another would be extra verbose. Some would use all the idioms, others would be 10 levels of nested braces. Every person's brain expressed itself differently and it was much harder to find common ground. Eventually I left perl for python, which seemed to be more sane. It seemed pythonic was more of a thing and the code was more readable. Also, it had a large standard library and you didn't have to leave the language to solve just about any problem. It did require extra effort to write code, but the benefits were pretty obvious. A couple other sort of random points - perl 6 was delayed and that might have hurt the language. Just the same python 3 did come out, but the 2 to 3 changeover was a huge negative to the language.