Then let it die in maturity, going down providing value to its users to the last, and focusing on any needs its remaining users may still have. Way better than stabbing it's user base in the back, and still not attracting any new users. Because there's no feasible way Perl can just tweak a couple things and open up a new user base. It is what it is.

The whole "stab our existing users in the back and chase a new user base" model has been bizarrely popular lately, but I'm not sure I've seen it work even once.

(I exaggerate a bit with "stab", but still...)

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.

Tcl still gets updates despite a small user base. Perl can enjoy the same fate.

I like to play around with trying new languages a lot. I've probably read a book on and written a little code in ~20 languages in the past decade, although 90% of my work is in Python. I didn't start playing with TCL until roughly a year ago and have been really impressed with what I've seen so far. Ashok Nadkarni's book is amazing and a lot of things seem pretty straightforward.

> I just don’t see a compelling reason to start a [X] project in 2020.

Fill in the [X] with your choice of language. It's not like it was 20 years ago when you chose a language because it was literally the only practical way to do what you needed to do. Unless you have something pretty niche, there's always another language.

I don't see a compelling reason not to start a Perl project in 2020. Granted, I don't use the language much, but I think it still has its place.

I'm not sure I understand. The situation for X = Javascript is very different to, say, X = SNOBOL.

Offhand there's also TypeScript, Dart, and CoffeeScript instead of javsScript (kinda, they do compile into it, but are conceptually distinct).

GP's point was that we're no longer in the situation where only one language is capable of doing what you want, so there's no "compelling reason" to use a particular one. You can pick the one you like instead of being compelled to a particular one.

> javsScript

Oh wow, that headache I had earlier really got me. I remember thinking "should I capitalize 'script' or not?" since I usually wouldn't but it's the right way to type both TypeScript and CoffeeScript and it looks nicer to be consistent and not technically wrong, but didn't notice "javs" at all.

Much too late to edit it now.

A "compelling reason" is not just about language capabilities. It's also about how easy it is to find developers for said language, what quality is the tooling, how stable is it anticipated to be going forward based on its history etc.

Can you give an example of a new project that you think would be right to start with Perl today?

Most examples that come to mind for me would make more sense as Python.

Anything that already exists in my shell's history as a one-liner, but needs to be upgraded to a reusable script.

As far as I know, one liners are not possible in Python. As a matter of fact, I'm not aware of any popular tools that can even hold a candle to Perl's power at the command line. So, my options are:

1. Forget about one-liners. This is the option most people seem to take, and also by far the worst one. In my career I regularly saw my perfectly competent colleagues take minutes or hours to write throwaway scripts to do what I would do in seconds with a Perl one-liner.

2. Use Perl for one-liners, then rewrite the few that graduate to scripts in Python. This one isn't as obviously absurd as the first, but still seems like a rather large waste of time overall.

3. The obvious: paste your one-liner into a new file, add some newlines and whitespace and command-line options and whatever else.

That makes sense!

When I write one liners I tend to build them up in bash, and so when I want them to be reusable I do the same as your (3) but targeting bash. Then when they get at all complicated I rewrite in python.

The thing about bash is that it's much less powerful than perl, while at the same time being more prone to surprising, undesirable behavior and write-only code.

The worst of both worlds.

I agree that bash has a lot of flaws, but on the other hand it makes a much better shell than perl. I really value using the same language for ordinary interaction with my computer and automation of very simple tasks.

We must do something -> this is something -> We must do this

What’s wrong with letting the language die?

That would be quite a waste of a good thing. It’s a really fun and powerful language.

I don’t use it anymore because of the culture of hating on it from non-users, who have just hounded users so much that they have succeeded in dampening the fun a lot. I mean you can’t even talk about it in HN without encountering some serious negativity, usually uninformed. It’s unpleasant.

On the good side, there are other great languages that don’t have this problem.

Sounds much like sunken costs fallacy. ;)

I don't follow you.

Sunken costs fallacy would apply if someone said "well, I spent so much time learning it, I might as well keep using it even though the environment is so hostile."

So, that's exactly the path I'm not taking. I'm disregarding any sunken costs. The sunken costs fallacy applies to those who would cling on to a path, not those who leave it.

But maybe you're using it from a different perspective.

If it’s going to die anyway then what’s wrong in trying to modernise it and seeing if that does renew interest? Worst case scenario is people don’t migrate and that outcome is no different to if you hadn’t tried. So it feels like the only bad move is not to try at all.

If modernising it splits the community and doesn't suceed, you've redone the Perl6 fiasco, but probably killed both 5 and 7.

Is that better than driving Perl 5 to a stable end? I don't really think so. But I'm not involved in the development of Perl, I'll just keep writing Perl scripts until it gets hard to install.

Perl is going to die if they don’t do anything anyway. So absolute it’s better to risk fragmenting the ecosystem.

If your result for inaction is eventual death anyway, then the sensible thing is to go out swinging. At least that way you have a half chance of reviving the language — which is better than the zero chance you have if you do nothing.

It's wrong for those who invested their career on it. If they switch to a different platform they lose their compatitive value.

Also a company with a huge Perl code base there is large value in new developers who can become productive without much special training.

Why would you hang your career on the fate of a single language? Most of the knowledge transfers just fine between languages. Over a career you can become an expert in several of them.

I have to disagree with the second part.

You shouldn't hang your career on any one language. But languages themselves are almost trivial.

Knowledge of libraries, and community expectations around them, doesn't translate well between languages.

And personal libraries, laden with solutions for the domains you've tended to specialise in, don't translate at all. You basically have to start from scratch, which is a huge loss if they are genuinely useful and took years to develop and accumulate.

You can't just rewrite those quickly, and you're unlikely to find a third party library in any language that solves the same problems.

I can see how this may be meaningless to someone whose career consists of moving from company to company, never carrying anything forward other than what's in their head. But some people carry forward substantial personal libraries which they use.

The loss of those can easily be a 10x loss in productivity, so switching to a new language and its entire ecosystem can be a big and expensive step, compared with not doing so.

Yes, over a career you can become expert in several. I would even say quite a lot. And yes, you can always learn new things.

But there will be times when you lose a lot of your advantages due to starting from scratch with something new. That's a big cost, it shouldn't be ignored.

When it's necessary, such as learning an ML framework, say, it's a justified cost, and everyone pays it.

But when it's just due to changing fashions it's a bit galling, and difficult to justify when is the right time. So much is lost.

> Most of the knowledge transfers just fine between languages.

A rather low-level example (nothing like understanding good abstraction/design), but useful because it's apparently not obvious - co-workers didn't believe it until I demonstrated with short example programs: Reference semantics are identical between javascript, python, and java.

(The first two being the primary languages we use, I don't remember how java came up that day - I know others are also the same)

You can certainly know multiple languages, but if you are involved deeper in the runtime and language design there is specific investment. I myself did a lot of PHP, went deep into the engine, nowadays do more with other languages where I can transfer some knowledge, but I guess even 5 years after writing my last relevant amounts of PHP I could jump in a consulting gig easily, while for other environments I have to spend more time preparing.

Blub languages are all alike; every powerful language is powerful in its own way. It's hard to reuse what I learned about Lisp macros or Python decorators or Scala implicits in other languages that don't have anything like that. The result tends to be reams of cringeworthy boilerplate because that's the only thing that works in every language.

there won't be new developers if they don't move the language past its present state. there's no reason for anyone to learn perl except for a job maintaining legacy software at this point, but that could change if they manage to refashion it to attract new interest

that said I don't know what kind of "special training" you need to pick up a new language. I got hired for a perl job despite never having written it. the conversation went something like "can you write c?" "yep." "can you write shell scripts?" "yep." "ok, you can write perl." read what the sigils meant and could write it with minimal competence same day. expertise and nuance can come as you go