Edit - to be clear - I don't think this is a good idea. I'm not inverting the meaning of the "bird in the hand" idiom, I used it specifically because I think this is an example of chasing after a fantasy that's going to leave them worse off in the long run by compromising their existing user base. I don't know why you'd expect a sudden rush of new users coming to Perl today and try to tailor a release to new users when, as the parent comment mentioned, new uptake is really limited and most users are working with existing systems/value stability.

The full proverb is "a bird in the hand is worth two in the bush." I recognize that you didn't quote this directly.

I am not sure if you meant to invert the common meaning here. The thrust of your post reads as if favoring this new direction for Perl, on the basis that it will bring in new users. The "bird in the hand" proverb would counsel the opposite - favoring stability to cater to current users, regardless of the impact on potential new users.

The reason for this is that the bird in hand is certain. The value to the bird-holder of the free birds must be discounted based on some probability that the bird-holder may capture these birds.

The implication is that to go bird-hunting, one requires two hands. In order to attempt to capture the two birds in the bush, one must first relinquish the single held bird. Bird hunting has some probability of failure. If you hunt for the two birds in the bush (by first letting go of the bird you have), you may end the day with no birds to your name, a position that is leaves you worse off than if you had simply held your bird in hand.

In the case of Perl and its userbase, the bird in hand consists of existing users who value stability and portability (per the article). The birds in the bush comprise current Perl non-users. There are more current Perl non-users than users. Pursuing current non-users by means that alienate current users may leave the language with fewer total users if there are simultaneously

1. A low rate of non-user to user conversion

2.And a high rate of user to non-user conversion.

Several references for the proverb, usage, and origins:

https://writingexplained.org/idiom-dictionary/bird-in-the-ha...

https://en.wiktionary.org/wiki/a_bird_in_the_hand_is_worth_t...

https://www.phrases.org.uk/meanings/a-bird-in-the-hand.html

https://grammarist.com/proverb/a-bird-in-the-hand-is-worth-t...

In Spanish, the proverb is "A bird in the hand is worth more than a hundred flying." and according to https://translate.google.com/translate?sl=auto&tl=en&u=https... it comes from a Latin proverb that is "A bird in the right hand is better than four out (of it)."

I think this is exactly it, and I also think it's the right thing to do. The antagonism to existing users (that don't want to change versions) is minimal. To them, it's just that Perl won't release anymore after a while, but there will be third parties to step in and offer support. I'm sure ActiveState is very interested in Perl 5 right now.

All this is is a recognition that Perl has been in maintenance support mode for years now, and providing a clean and clearly defined way for people that are interested in changes to opt in to them.

As a community, I think this is clearly the correct choice. The (current) nature of programming language communities and new user means that a large percentage of new users comes into programming each year. For a community as small as Perl, if you can increase the amount of those people that are coming to your community even minimally, it will probably dwarf the existing community fairly shortly, and that's needed if it's to survive at all.

I do and have developed Perl as either my main or one of my main responsibilities in by job for over two decades now. Perl 7 won't change how we do anything at work for years, if ever, since we have decades of Perl code to maintain and extend. I still am extremely happy about Perl 7 because it's the first time I've been excited about a Perl development in quite a while, and because I can't see any negatives for our existing code.

And that won't change unless Perl is allowed to change.

Nobody is going to hail perl 8 as the hot new thing, the only thing that will happen is this move killing perl off entirely.

Nothing there looks as drastic as the big changes from python 2 to 3, for example.

I also created and maintain a large Perl stack and in my opinion, the things that made Perl great 10-15 years ago, other languages have adopted and did better. Now for lack of want of updating the language, it’s just languished. I just don’t see a compelling reason to start a Perl project in 2020.

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

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

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

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.

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.

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

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?

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?

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.

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.

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.

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

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.

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 worst of both worlds.

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.

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.

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.

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.

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

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.

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)

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

by loc I've probably written more perl than any other language, maintaining a massive legacy codebase at a previous job. I will probably never write perl again, and the idea of starting a new project in it is unthinkable to me. nevertheless I can see how it could find a new batch of users as a comfy expressive intuitive scripting language, if they can clear out some of the deadwood. it's certainly more suited for that role than python or js. and honestly I doubt it will break much given, as you said, no one running legacy perl ever updates their perl version anyway

the real reason why this is being done probably is that the maintainers love their language and want for it to continue to live rather than die a slow death. I wish them luck

Use Major Version to break compatibility when it is necessary and bring performance advantage as incentive to switch. It is not one or another but both.

Where there are business value in switching, they will.

It's never going to happen. They don't even think of performance as an important value to have [1]. And in current implementation (without redesigning the language) AOT and JIT compilers are too impractical and too costly to implement.

[1] Even though benchmarks-marketing is a known way to attract users.

I'm assuming that sort of thing will continue, but with less backporting to version 5. Jitting just the regex engine without compatibility problems is one potential thing that could happen. PCRE2 is pretty close to that now.

I don't know who you think "they" are but that statement has not been true for a few years now.

A lot of ticketing platform for the 2008 Olympics was Perl, and I was responsible for one of the engineering teams.

The first on-sale basically flopped because our load testing environment had a different version of DBD::Oracle.

On the other hand, I'm a bit worried about Cor; it feels like Ovid is trying to repeat in a few months the same work that TimToady took a few years to do. A good object model is nontrivial, and it feels a little rushed to meet an arbitrary deadline. And I generally feel that Moose syntax is not that great, and it's making a lot of the same mistakes. Maybe I'm not the target audience for this.