Comment by mmaunder | Hacker News Reader

Comment by mmaunder | Hacker News Reader

While the authors accusation audit is impressive, I can assure you, as a CPAN contributor and someone who has launched some very successful Perl web apps, that Perl is in fact, completely and utterly dead. It died well over a decade ago when all focus moved to Perl 6 which didn’t emerge until recently. Everyone moved on except a hardcore group of advocates. They aren’t coming back. If a new language and community emerges that happens to have the same name, I’ll certainly take a look. That hasn’t happened yet. And it’s a damn shame because the mod_perl list and community had some killer talent in it that was creating the most innovative and heigh performance web applications out there. I created WorkZoo in Perl which was a very high performance job meta search engine and was one of Time Magazines top 50 sites in 2005.

What happened to Perl is a damn shame. Many of us went over to PHP which is vibrant, keeps getting faster and better and is as practical as Perl was and hasn’t stalled.

>Many of us went over to PHP which is vibrant, keeps getting faster and better and is as practical as Perl was and hasn’t stalled.

Funny as, quite similar to Perl, it took about a decade for a new major version (v. 7) and in the meantime there was a failed experiment (v. 6). And, quite similar to Perl, people were saying PHP is a dying language only alive thanks to some old major projects (WordPress, ...) that are written in it. Moreover, exactly like this very blog post, there were articles written saying that PHP is not dead.

You also had facebook pumping resources into PHP with HPHPc, HHVM, trying to compile a spec, etc.

That definitely would have helped keep PHP alive through the period between PHP 5 and PHP 7.

Additionally, PHP's releases of 5.3, 5.4, and 5.5 introduced enough new functionality that the bump was more than incremental. It had backwards-breaking changes, which should have warranted a new major release if PHP followed semver.

Old Programming Languages never die, they just fade away.

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?

Release cadence. Trendy isn't a factor for a productive dev.

> Trendy isn't a factor for a productive dev.

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).

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.

Do you have any other programming language related tattoos of so that people know those are going to die too?

I do not currently. Not sure Ruby is dead yet though...

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.

What's the status of your Rust crab tattoo?

I've been joking that I only get tattoos of languages I don't really use anymore.

Also that "RUST CRAB" would fit on my knuckles...

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.

> still more cows than other not-dead languages.

It may still have a lot of cows, but it clearly doesn't have many calves and that's the statistic that speaks to the eventual fate of the language.

I think Perl 6 killed Perl 5.

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.

Why didn't Python 3 kill off Python in the same way?

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.

Because it existed. You could actually write a Python 3 program.

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.

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.

I think that describes Perl v7 pretty well.

It describes other Perl-like languages like Python, Ruby and PHP pretty well too.

Why would I want to go back to Perl when I could use a language that’s more popular and well-established now?

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.

Too many ways to do things. TIMTOWTDI.

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.”

> The "line noise" stigma?

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.

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.

I mean, its relatively trendy right, compared to Perl?

Many still hold it up as a model PL in various ways. I'm always promoting it myself ;)

>>Many of us went over to PHP which is vibrant, keeps getting faster and better and is as practical as Perl was and hasn’t stalled.

Who uses php these days?

I haven't heard any one start a new php project in years. Ruby seems to have gone the same way.

Python seems to have won the backend game, which actually makes sense as Python today is bloated like how Perl was once. And these days it feels like Perl with tab indentation. No wonder it fanatic following these days.

Frontend game is now owned by Node, ReactJS, JS etc.

Who uses php to do anything? In fact I don't know of a single college kid I've hired who has even looked at php let alone used it.

WordPress, Drupal, Magento, Joomla, OpenCart and lots of other open source community CMS and online web-store type things are built on it. Sadly it will never die because it has Facebook pouring money into it.

Why is "college kid skills" relevant for anything? Do you make tech and business decisions based on what your incoming jr people want to do?

Many people in my circles use PHP for ... lots of stuff. I just got back from a PHP conference, and saw hundreds of people there are using it.

"Python seems to have won the backend game" - I'm really curious where you get that impression from. I can't imagine it's relating to publicly available web servers. That's not a total view of everything, of course, but... absent other numbers/studies/reports, it's really hard to draw any conclusions that aren't just based on personal experience.

Reply on news.ycombinator.com