| ▲ | mmastrac 3 hours 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. |
|
| ▲ | nine_k 3 hours ago | parent | next [-] |
| 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 2 hours ago | parent | next [-] | | > "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. :) | | |
| ▲ | hinkley 2 hours ago | parent | next [-] | | 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. | |
| ▲ | nine_k 2 hours ago | parent | prev | next [-] | | Exactly. Perl is about experimenting, trying things your way, and discovering new and good ways to write programs. Which is a wonderful capability for research and discovery, and for art or recreation, but not that great for industrial production. This is why Perl was quite fit for the job at the dawn, or, rather, the detonation phase of the Internet explosion in late 1980s and early 1990s, along with Lisp and Smalltalk that promote similar DIY wizardry values. But once the industry actually appeared and started to mature, more teamwork-friendly languages like Java, PHP, and Python started to take over. | |
| ▲ | creer 2 hours ago | parent | prev [-] | | > 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 an hour ago | parent [-] | | 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. |
|
| |
| ▲ | Scarblac 2 hours ago | parent | prev | next [-] | | It could have used a good "Perl: the Good Parts" book. With a team where everybody wrote it in a similar style, Perl did perfectly well. Mod_perl was fast. I liked Perl. Then Django came out, and then Numpy, and Perl lost. But Python is still so incredibly slow.... | | |
| ▲ | tasty_freeze an hour ago | parent | next [-] | | Check out "Perl Best Practices" by Damien Conway, and the more recent "Modern Perl" by Chromatic. Both can be had as paperbacks, and I think both are also available free on online. | |
| ▲ | creer 2 hours ago | parent | prev [-] | | Mostly - from here - python is so incredibly slow to write. Who has this kind of time? | | |
| ▲ | ipaddr 2 hours ago | parent [-] | | Slow to write, slow to run and throws whitespace errors. Surprised it made it so far. | | |
| ▲ | altairprime an hour ago | parent [-] | | Sounds exactly like academia itself, and is probably a selling point if you’re a business. |
|
|
| |
| ▲ | athenot 2 hours ago | parent | prev | next [-] | | In a similar vein, as the industry matured, we went from having teams of wizards building products, to teams of "good-enough" developers, interchangeable, easy to onboard. Perl culture was too much about craft-mastery which ended up being at odds with most corporate cultures. Unfortunately, as a former Perl dev, it makes a lot of other environments feel bland. Often more productive yes, but bland nonetheless. Of the newer languages, Nim does have that non-bland feel. Whether it ends up with significant adoption when Rust and Golang are well established is a different story. | |
| ▲ | hinkley 2 hours ago | parent | prev | next [-] | | The big pearl of wisdom I took from Larry Wall seemed to be counter to the culture I experienced looking in from the outside. That always confused me a bit about Perl. And that was, paraphrased: make the way you want something to be used be the most concise way to use it and make the more obscure features be wordy. This could have been the backbone of an entire community but they diminished it to code golf. | |
| ▲ | Klonoar an hour ago | parent | prev | next [-] | | It is not a great language. It is, however, a significant language. It has left a mark and influence on the culture and industry of programming. Nothing to sneeze at. | |
| ▲ | morshu9001 2 hours ago | parent | prev | next [-] | | Couldn't they have figured out one decent way to do things before releasing features to all users? I tried Scala for a bit then decided it was complicated for no good reason. Idk about Haskell, but I used Erlang which is also purely functional. No matter how long I used it and tried to appreciate its elegance, it became clear this isn't a convenient way to do things generally. But it was designed well, unlike Scala. | | |
| ▲ | jerf 43 minutes ago | parent | next [-] | | Erlang is, by my accounting, not even a functional langauge at all. It takes more than just having immutable values to be functional, and forcing users to leave varibles as immutable was a mistake, which Elixir fixes. Erlang code in practice is just imperative code written with immutable values, and like a lot of other modern languages, occasional callouts to things borrowed from functional programming like "map", but it is not a functional language in the modern sense. If you go to learn Haskell, you will find that it has a lot to say about functional programming that Erlang did not teach you. You will also find that you've already gotten over one of the major hurdles to writing Haskell, which is writing with immutable values, which significantly reduces the difficult of swallowing the entire language at once and makes it relatively easier. I know it's a relatively easy path because it's the one I took. | |
| ▲ | dtauzell 16 minutes ago | parent | prev [-] | | If you wanted to write a quick on off script then using magic variables,etc made sense. Writing something you’ll keep? Don’t use those. When Perl 5 introduced references they could have simplified the syntax though. |
| |
| ▲ | eduction 2 hours ago | parent | prev | next [-] | | Not really. It wasn’t audacious in service of anything innovative. Haskell takes functional programming to the nth degree, scala tried to be an advanced Java for example better at concurrency. Perl was an early dynamic (garbage collected) “scripting language” but no more advanced than its contemporary python in this regard. It had the weird sigils due to a poor design choice. It had the many global cryptic variables and implicit variables due to a poor design choice. It has the weird use of explicit references because of the bad design choice to flatten lists within lists to one giant list. It actually was the one thing you said it wasn’t - a good practical general language at least within web and sysadmin worlds. At least until better competitors came along and built up library ecosystems. | |
| ▲ | 2 hours ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | atherton94027 3 hours ago | parent | prev | next [-] |
| 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 3 hours ago | parent | next [-] | | 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 (http://www.stonehenge.com/merlyn/UnixReview/col38.html) | | |
| ▲ | PunchyHamster 2 hours ago | parent | next [-] | | 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. | |
| ▲ | weare138 2 hours ago | parent | prev [-] | | 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. |
| |
| ▲ | totallykvothe 2 hours ago | parent | prev | next [-] | | That's not super subtle any more than it's super subtle that "*" performs multiplication and "+" performs addition. Sometimes you just need to learn the language. This is not a general defense of Perl, which is many times absolutely unreadable, but this example is perfectly comprehensible if you actually are trying to write Perl and not superimpose some other language on it.* | |
| ▲ | creer 2 hours ago | parent | prev | next [-] | | What exactly is complex or "super subtle" about this? It's the textbook example from the 1st chapter in the tutorial or something? | | |
| ▲ | atherton94027 2 hours ago | parent [-] | | It's just very non-obvious what the code does when you're skimming it. Especially in a dynamic language like Perl, you wouldn't know that you're passing down an integer instead of a function until the code blows up in a completely unrelated function. | | |
| ▲ | weare138 2 hours ago | parent [-] | | Then use one of the type systems for Perl. https://metacpan.org/pod/Type::Tiny | | |
| ▲ | creer an hour ago | parent [-] | | You can't do that if you gave up at the very first sigil puzzle. I'm fine with that: to program in Perl you need to be able to follow manuals, man pages, expert answers, - and even perl cookbooks, or CPAN or web searches. It's a technical tool. The swiss army chainsaw. It's worth it. | | |
| ▲ | atherton94027 an hour ago | parent [-] | | Seems like you and a few other posters are making the article's point – that Perl's culture is hermetic and that new programmers would rather learn Python, Ruby or Javascript rather than figure out which sigil means what. | | |
| ▲ | creer 30 minutes ago | parent [-] | | I wouldn't call it hermetic in that the many forms of documentation are insanely thorough and accessible - if not well advertised. There is no gate-keeping (from my point of view). New users are welcome. It's easy to learn (for the people for whom reading is not an obstacle). But yes, no contest that the world has been on a simplicity binge. Python won by pushing simplicity and by having giant software corporations choosing it (and not complaining about the line noise nonsense). If you want to go into programming professionally, for now many years, you need python. I don't know that I would put Javascript in the same bag. I mean, it's the other way: it looks simple and it isn't. But python, yes, python won because it looks simple and google pushed it. Many other languages now have to reckon with the python supremacy. This is not specific to perl / raku. It will take work for anything to replace python. |
|
|
|
|
| |
| ▲ | agumonkey 2 hours ago | parent | prev | next [-] | | I always found contextual eval interesting. It's a generalized version of toString in a way | |
| ▲ | petre an hour ago | parent | prev [-] | | It's not complexity, it's magic. Useful when one cannot be bothered to write array.length. So is if (@a) when the array is empty. |
|
|
| ▲ | frankwiles 3 hours ago | parent | prev | next [-] |
| 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. |
| |
|
| ▲ | eduction 3 hours ago | parent | prev | next [-] |
| I agree and Steve Yegge covered the reasons well here: 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 an hour ago | parent [-] | | > 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. |
|
|
| ▲ | MangoToupe 3 hours ago | parent | prev [-] |
| 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) |
| |
| ▲ | zahlman 3 hours ago | parent | next [-] | | > 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. | |
| ▲ | jordanb 3 hours ago | parent | prev | next [-] | | 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. | | | |
| ▲ | zihotki 3 hours ago | parent | prev [-] | | > 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. |
|
