Hacker News Reader

Comment by lmiller1990 | Hacker News Reader

lmiller1990

I think most people using Perl for anything non trivial (eg, large web app with Catalyst) are unlikely to be changing their version of Perl without a good reason, and very few people are starting large Perl projects now days. My day job is working on a fairly complex app running 5.28.1, we have no desire to change the Perl version without a very good reason to do so.

I find this post a little unsettling. It seems like even the Perl community is unsure why they are doing this.

At least for me, Perl === Perl 5 (and probably always will). It works, and it's ecosystem is very mature.

View on HN

I think the reason is probably what you mentioned - very few people are starting large Perl projects nowadays. And I think they'd like that to not be the case anymore by making it attractive to newcomers. Feels a bit like a bird in the hand vs two in the bush type thing honestly - be a bit antagonistic to your existing user base and make up on the hope that you'll get a new rush of users to make up for it.

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.

Just a note, that the idiom, "bird in the hand" is a statement that one should value that which they already possess over that which they do not yet possess, even if the latter is ostensibly worth more than the former.

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.

I'm not inverting the meaning. I used that idiom precisely because it conveys the meaning that going after the two in the bush can leave you empty handed. I think this is a terrible idea and that antagonizing your existing users on the hope that new users will start using perl is going to kill your community, and I hope that the real reason for the decisions made around Perl7 are not actually to attract new users by compromising what the existing user base cares about. The post wasn't supposed to read as if it favors the new direction - sorry if that wasn't clear, it was supposed to convey the exact opposite through the use of the bird in the hand idiom and dismissing the birds in the bush as a mere hope that they'll get a rush of new users.

Gotcha. That's my misreading, and I apologize for that.

I don’t actually think that’s what it means. I thought it meant when you have two birds you can go after, if you go after both you may catch neither, but if you go after just one it’s better than having caught none.

It means you already have caught one bird (the one in your hand), and that’s more valuable than giving that one up for the chance to try for two that you have a low risk of catching (the two in the bush) because you have to release the one in your hand if you want to try for the two on the bushes.

The proverb is "a bird in the hand is worth two in the bush." It posits a scenario with three birds, one held in the hand, and two free in the bush. We can assume all bird have the same intrinsic value. If each bird has the same intrinsic value, the only way one can be worth more than two is from a subjective perspective. From the perspective of the bird-holder (who is defined to hold one bird), that bird in hand is worth more than the two free birds.

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

It's interesting that the number of birds change a lot from language to language.

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

And the Swedish version I've heard compares one in the hand against ten in the woods!

Also, even if you can catch the two birds for certain, it might not be worth it. For example, it could require more than one birds worth of calories to catch two birds, so the bird in hand that costs zero calories is the strictly superior option.

The generally accepted meaning is that already having something (the bird in hand) is worth more than chasing after things that you don't have (the birds in the bush). So in this case, the idea is that customers you've already acquired are worth more than a larger, untapped market. The poster has flipped this accepted meaning to suggest that Perl should chase after new users, rather than focusing on keeping existing users happy.

> be a bit antagonistic to your existing user base and make up on the hope that you'll get a new rush of users to make up for 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.

> I think the reason is probably what you mentioned - very few people are starting large Perl projects nowadays.

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

And how many people are going to start new perl projects after all existing codebases get broken? Especially considering their "values" now include breaking your code all the time.

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.

As far as I can tell, the changes being made are relatively easy to absorb. Either the right way, or by using a pragma/directive.

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

Something’s gotta change though. The path perl5 is on ends in dead language. It’s not attracting young talent, the last really high profile project that sticks out in my mind is Perl Dancer which was released in 2011, and modules on cpan are getting dusty/losing maintainers.

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.

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

I think it makes sense. perl6 was a huge distraction that went on far too long, leaving perl5 to stagnate, and then it came out and hardly anyone had much use for it. now that perl6 isn't "perl" anymore, perl7 is basically a "second chance" at evolving perl5 after it was frozen in amber for over a decade

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

I think it's likely that Perl 7 will eventually improve performance in a significant way. That would create a compelling reason to upgrade, either for customer experience or cost reasons.

That is the thing.

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.

> Perl 7 will eventually improve performance in a significant way

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.

There have been performance improvements in Perl 5 over the last 5 years. Nothing dramatic like a JIT, but a collection of smaller improvements that add up to something significant.

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 did that. It's not that big of a performance gain. My jit will for sure, but I ran out of funding. My signatures and types provided a 100% speed boost.

Kudos for your efforts. I've watched from a distance and been disappointed with the politics.

> They don't even think of performance as an important value to have

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

I learned this lesson the hard way.

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.

At my job, we're relatively optimistic about Perl 7, and will probably be willing to move over a few months after a stable release. Yes, it's a mature product with 3 million lines, but the requirements are easily to meet if we make a modern product. Not doing indirect method calls? Most of those are gone years ago, and for good reason.

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.

Reply on news.ycombinator.com