What's missing from Perl 5, would you say, that's holding it back? Performance? Language features? The "line noise" stigma? (yet, Haskell is trendy and it's at least as "line noise" looking to me, in typical use, as typical Perl is...) Package management and other tools?
This is a bit like asking what's wrong with your ranch by describing the grass. The problem is there's no cows on it.
You might argue that sufficiently appealing grass might persuade cows on other ranches to jump the fence and come over, but the reality is that the grass on those other ranches is very nice at this point and getting greener faster than the grass on Perl Ranch.
The users are gone and aren't coming back. Without those, you don't have a language.
I have a tattoo of a Perl camel, and of a Ruby ruby. I loved Perl, but to me anyway, Ruby was 95% of the good stuff of Perl, with 5% of the downsides. Some of that last 5% of good stuff was things that you could even argue isn't actually good stuff, but I like it anyway. ($_ is my go-to example for this.)
"Why not {Ruby,Python,PHP,JavaScript}?" is imho the question that Perl has to answer, and hasn't found one that enough folks find compelling, it seems.
This thread is making me so nostalgic... it's hard to overstate how influential Perl was on me.
I'd definiely switch to Roby anytime now that it's also faster, post 2.5. But our codebase is written in Perl 5. Why now Perl 6/Raku? Because it's slow and also has a smaller community around it.
I like your analogy. But the more accurate statement is that perl has a fraction as many cows as it once had, but still more cows than other not-dead languages. It still gets more daily uploads to CPAN than Haskell gets to hackage.haskell.org packages, for instance.
Perl spent almost 20 years with a new version looming over its head. It was known from the start that Perl 6 would be incompatible. This meant it always seemed to be a bad time to get into Perl. You were committing to having to do a partial re-write whenever Perl 6 happened to come.
As more time passed and the differences between 5 and 6 became bigger, companies that had been holding out for Perl 6 started to ask "If I'm going to have to do a re-write, why not re-write in something else?". Which is what we ended up doing.
I think there are various other warts in Perl compared to other languages in its niche, but I don't think they killed the language.
I think you are absolutely right. The warts only exacerbated the process you describe, because when potential new users checked out Perl and saw the warts, it seemed a lot easier to wait for the new version that was supposed to address many of them. So new users as well as existing users put off investing in Perl until the next version. In the early 2000s, it didn't make sense to learn Perl 5 unless you had an pressing need, because Perl 6 would be out soon and would have a much easier learning curve.
Perl 6 has to be one of the most destructive failures ever committed by the stewards of a popular programming language.
It feels like it almost did. There was a pretty frustrating couple of years there where it wasn't clear if 2.x or 3.x was going to be the winning version and the Python community seemed to have a lot of disagreement on that subject. My team invested heavily in alternatives like Node.js at the time to hedge against Python dying.
However, Python 3 did at least eventually have a reasonable backwards compatibility story which Perl 6 never really seemed to have. It's a bit harder to do now since Python 3 has marched on while Python 2 is formally unsupported now, but for a while in the 2.7/3.3 days, it was relatively straightforward--if a bit icky at times--to have a single code base that would support either version of Python, and many library and app developers took advantage of that to allow as-seamless-as-possible transitions, rather than the whole community having to immediately spend a ton of effort porting their entire code bases to an incompatible language. Mechanical code rewriting tools which were introduced during that period like 2to3 also helped ease the transition for many use cases and code bases, too.
The downside of all that is related: Since source compatibility was possible, the package distribution method remained the same, and at the same time for all the usual reasons, some useful packages never got updated with Python 3 compatibility changes. Today, there are still libraries in PyPI which can be pip installed with Python 3, but you can't actually use them because they never got the attention needed to be compatible with it. If the package is a pure Python code base, you might not even find out until you try to import the library or call a function, class, or method. Then you get to spend time in your favorite search engine trying to hunt down an alternative. Very annoying.
First, Python 3 wasn't intended to be a significantly different and superior language. It was always intended to be a one-time chance to fix warts and unfortunate decisions, not change the look of the language. For a beginner, the difference would look superficial, even though some of the changes were deep. One of the most fundamental, valuable, though ultimately troublesome changes was to change the string type from byte strings to Unicode strings, a change that to a beginner looks like a simple upgrade. You could start learning Python 2 and switch to Python 3 later at very little cost, or, as an experienced Python 2 programmer, you could feel at home writing Python 3 very quickly. You could also learn Python 3 and then go interview for a Python 2 job, because nobody would worry about your ability to adapt.
Second, Python 3 existed, which renders every other comparison hypothetical. For example, the Perl 6 project was supposed to deliver a language-agnostic runtime that would run Perl 5 code and allow it to be used by and used from Perl 6 code. Hypothetically, that might have been a superior way of providing continuity to the community than what Python 3 did, but we'll never know.
If you went looking for the best practices, you would find a few things but mostly you would find garden path tutorials leading you through many suboptimal ways of doing things and then finally recommending a final, also suboptimal, way. There was a book on Perl best practices that was full of recommendations on how to do things, and after not too long many of the techniques were deprecated. In other words the book was wrong yet it was the go-to book when it came out. Sure it’s normal for tech books to get outdated but this seemed to be a different level.
Then you hop over to the Python docs and see this phrase, paraphrasing here, “there should (generally) be one preferred way to do it.”
This is what kills it for me more than anything else.
Perl's syntax is incredibly unintuitive. People joke about it being the only "write-only" language because you can write some code and 6 months later come back to it and have no idea how any of it works.
Code is read far more often than it is written, so readability is important, and Perl lacks it.
You can, but you don't have to. With some self discipline, Perl can be very readable. The only problem is that actually requires skill and agreement in development team. Perl Best Practices helps with that.
The strict guidelines followed by the one Perl shop I worked at briefly kept things very simple, but also very different from the "Modern Perl" revival that was being pushed back then, in the early 2010s.
The company I worked at maintained some ETL pipeline on behalf of Yahoo, and the strict guidelines from the client and the ones developed internally stayed you from using anything coming from CPAN.
That means that you didn't get to have function signatures, as those were a package back then, you had to declare all your arguments at the beginning of the subroutine body by taking them off the implicit parameter variables.
Programming in it wasn't crazy for sure, but it just felt like a really clunky Python. The split between the data structures that could be handled by reference and the ones that didn't was very unfortunate, Yahoo mandated that you only use the ref-type, and you had to be converting back and forth.
Well, that was part of my experience working for some 6 months at a team where strict discipline kept a big system working, but there was little upside to using Perl. The worst was the error handling in this scheme, keeping your own makeshift stack trace with backing up the error variables was a hassle.
A reasonable syntax, try/catch/finally built in, subroutine signatures as a default feature (not 'experimental') and a sane class system would be a start.
The class/package system is actually my favorite part of the language, and the reason I put up with the syntax warts. It goes one step better than JavaScript by putting methods and attribute storage into separate namespaces, and supports multiple inheritance, and lets you modify the method tables on the fly.
Why do you believe Haskell is trendy? I love it as a language but it seems very much not trendy in terms of usage vs something like rust where a lot of people seem to be doing things.
It can matter, since companies want to see experience with what they're using, when they hire, so developers don't want to get stuck in something that's declining. Hype and perceived popularity-trajectory definitely matter for keeping a language alive, and for hiring (devs will tend not to want to take your job if they'll be working with things they consider to be legacy and trending downward).
