Perl 5 isn't going anywhere. It will be in "maintenance mode", which let's face facts, Perl 5 has been in for years. Once it's not supported by the developers anymore, I'm sure some third party will patch it, and some commercial ones (ActiveState) will likely be happy to provide more professional assurances.

> Way better than stabbing it's user base in the back, and still not attracting any new users.

I'm one of those users, and I'm very happy about this. I see it sort of as a family member opting for chemo rather than just waiting out the end. Sure, it might not work, and might be a painful, and might quicken the end slightly, but maybe it actually given them many more years at a better quality of life than they currently have.

Also, I don't really think it's stabbing them in the back that much. It's not like anyone using Perl 5 that doesn't want to change won't be able to keep doing what they're doing with close to or better support than they've had, if it plays out as I suspect (for professionals, there's a business opportunity to provide support to Perl 5 long-term, so someone will do so).

I guess I haven’t really considered that angle before, maybe the maintainers love it too much to let it die.

I don’t really know where I stand now. Maybe they should just leave it alone. I just stare wistfully at the hole PHP has dug itself out of over the past decade in terms of modernizing the language, and its 2020 and I can’t even have subroutine signatures without experimental flags. I feel like opportunity was missed with Perl and I don’t know if it can be reclaimed.

PHP was always one of the top ecosystem for web development (probably the top one in the early 2000s), with strong platforms and userbases centered around them: LAMP, wordpress, discussion boards and other.

Perl never had anything like that. It allowed to do CGI in the early 1990s then nothing major I can think of.

>> Perl never had anything like that. It allowed to do CGI in the early 1990s then it didn't keep up.

Not quite. Perl actually has several widely-used web frameworks such as:

Mason - https://en.wikipedia.org/wiki/Mason_(Perl)

Dancer - https://en.wikipedia.org/wiki/Dancer_(software)

Catalyst - https://en.wikipedia.org/wiki/Catalyst_(software)

Mojolicious - https://en.wikipedia.org/wiki/Mojolicious

Many of these were/are widely-used and most are still maintained and in use.

Mason powered the Amazon.com retail web site (maybe it still does?).

Catalyst powered DuckDuckGo's Community Platform, the BBC iPlayer, and YouPorn.

Depends what you mean by widely-used. After Rails and Django appeared I can't remember many high-profile sites using any of the Perl frameworks. Maybe Catalyst at the BBC and Net-A-Porter who hired a lot of Perl gurus. Perl's realy failure was competing with PHP. Perl's equivalent, HTML::Mason, really required mod_perl to perform anywhere near mod_php and that's what killed it as mod_perl was not an option for cheap hosting providers. PHP was as much a marketing coup as anything else, hence Facebook built on PHP. I think it says everything that Dustin Moskovitz mistakenly picked-up a Perl textbook before he was corrected by Mark Zuckerberg that they were using PHP. That's exactly where Perl stood in relation to PHP in early 2004.

Yes, that's how I remember it. It's also worth noting that the fun parts of perl were largely replaced by ruby. The ruby one-liners and perl one-liners are pretty much the same. And eventually, gems got bigger than CPAN.

You're also right about mod_perl vs php. Shared hosting was really common and mod_perl was really unpleasant.

At some point it's just goodbye perl and thanks for all the scripts.

Yes, there was real apathy in the Perl community - an attitude that Perl is a better language than PHP so why should we lower ourselves to compete. The endless MOP debates didn't help either and for those waiting for Perl to sort it out Ruby was there with everything they needed. Moose, Moo, Mouse - talk about fiddling while Rome burns. Perl was in no state to compete with Rails' elegantly-packaged Omakase. Another factor which affected Perl 5 in the mid-2000s was the diversion of resources to Perl 6 when Perl 5 had 3 sharks (PHP, Ruby & Python) circling around it. Meanwhile newsagents' shelves were full of dedicated PHP & MySQL magazines and the more generic web dev mags invariably had an advanced section featuring sites buillt with PHP & MySQL. It was already game over for Perl.

Mojolicious and Dancer (now Dancer2) are still very actively developed as well.

> I'm not sure I've seen it work even once

I've seen it work several times ... but maybe no interesting times. One example would be Algol58 to Algol60!

> Then let it die in maturity

That can be achieved right now for anyone who is interested: download Perl5.32 and never update it. No one will ever force you to upgrade to Perl7 if you don't want to. Why hold everyone else back when remaining in a static state can be done in isolation?

> download Perl5.32 and never update it

I think this is an interesting sentiment when contrasted with the Python 2/3 split, where most people are pushing to get projects into on 3 and warning users of 2 they will not be getting official security patches any more. Maybe because Perl's community is smaller they wouldn't be as hard-line on this and release security fixes for Perl 5 if they were merited (though I don't see Perl as a tempting target for malware authors).

It feels like that article states that some people in the Perl community want to make the breaking changes to free themselves of legacy and gain the advantage of accessibility from new users by doing so, being that Perl 5 desperately needs new users, but contrasts this with the fact that protecting that legacy was both a core value of the Perl project and possibly one that held it back for too long.

I honestly wonder where we would be if Python never made the 2/3 split and we'd all still be using Python 2 at this point with all of its design flaws. Surely it wouldn't die from becoming outdated, seeing other languages do the same things better, as with Perl?

This is about the direction the language development is going in the future, not the current artifact. You can still choose to focus on your current user base or chasing a different one.