Perl7 is a fork of values(blogs.perl.org)
blogs.perl.org
Perl7 is a fork of values
http://blogs.perl.org/users/leon_timmermans/2020/08/perl7-is-a-fork-of-values.html
144 comments
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.
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.
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...
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...
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.
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)."
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!
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 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 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.
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.
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.
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...)
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).
> 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.
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 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.
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.
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!
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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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)
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)
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.
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.
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.
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
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
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.
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.
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'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.
> 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 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.
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.
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.
I like Perl, and I think that changing the defaults is a sane thing to do. Starting a new script with dozens of "use strict", "use v5.30", etc is less than ideal and it's easy to forget something and shoot yourself in the foot. Almost 30 years will pass between Perl 5 and 7, and going back to the old values is just a matter of adding a few lines at the beginning of your old script. It's not a mess like the whole "Python 2/3" ordeal that was deeply more complex and painful.
Heck Perl in the last 30 years has been even more stable than C. I remember when gcc and clang switched from a default of GNU89 to GNU99 and it broke several packages who didn't set or check for the right flags; nobody bitched about it and just went on to fix their Makefiles.
Heck Perl in the last 30 years has been even more stable than C. I remember when gcc and clang switched from a default of GNU89 to GNU99 and it broke several packages who didn't set or check for the right flags; nobody bitched about it and just went on to fix their Makefiles.
I am not a Perl person, but it does sound to me like a lot of this thread is is missing what's going on, yeah. They're not changing the language, they're just changing the runtime to use better, more modern defaults. I don't know if you would be able to put in "use unstrict" or something and get back the old behavior, but any actively-maintained code is probably using most of these newer defaults anyway.
Brian D Foy wrote a pretty good post on this. https://www.perl.com/article/announcing-perl-7/
Essentially, it is just perl 5.32 with more modern defaults. They will keep evolving the language. Perl 5 isn't going anywhere.
Essentially, it is just perl 5.32 with more modern defaults. They will keep evolving the language. Perl 5 isn't going anywhere.
Had a chance to work with Leon on the TestAnything protocol. Really great guy to work with.
>I don't know where we're going. I'm not even sure if this forking is good or bad in the long run (it could be good if managed well, but so far it isn't). And that terrifies me.
Hopefully this new version will make Perl easier for newcomers. But maybe before the final decision they will find a compromise solution where some old features may be dropped, while making it not-so-hard to migrate Perl5 to Perl7.
>I don't know where we're going. I'm not even sure if this forking is good or bad in the long run (it could be good if managed well, but so far it isn't). And that terrifies me.
Hopefully this new version will make Perl easier for newcomers. But maybe before the final decision they will find a compromise solution where some old features may be dropped, while making it not-so-hard to migrate Perl5 to Perl7.
> Had a chance to work with Leon on the TestAnything protocol. Really great guy to work with.
Why thank you :-)
Why thank you :-)
Wait, hold on. They're talking about Perl7. Is this the next version after Perl6, which is called Raku? Or is Raku already completely forked off and now they're talking about another fork of what remains of Perl?
They are talking about the next iteration of Perl 5. https://www.perl.com/article/announcing-perl-7/
It's the next logical major version for Perl 5. Consider "Perl 6" to be a dead term.
perl7 is the continued development of perl5.
they skipped 6 to avoid confusion with raku.
they skipped 6 to avoid confusion with raku.
So now that Perl 7 wants to actively remove backwards compatibility from its culture, where are people to turn now for stable/non-moving scripting languages?
/bin/sh?
I am not sure what the balance of facetious vs serious is here. The various Unix shells have been stable for quite a while. Obviously sh is very barebones, but zsh and bash, for example, have associative arrays and other modern conveniences.
Outside of various shells, there are several other options that come to mind which do not teeter on facetiousness.
So far as I know, tcl is also quite stable.
Common Lisp is perfectly usable as a scripting language and has a very stable standard and mature libraries.
I am not sure what the balance of facetious vs serious is here. The various Unix shells have been stable for quite a while. Obviously sh is very barebones, but zsh and bash, for example, have associative arrays and other modern conveniences.
Outside of various shells, there are several other options that come to mind which do not teeter on facetiousness.
So far as I know, tcl is also quite stable.
Common Lisp is perfectly usable as a scripting language and has a very stable standard and mature libraries.
The reason I reach for Perl rather than bash is it has far more features and far easier to manage.
I don’t bother with python as you get into a horrendous mess with pip breaking and the v2/v3 issue.
Not every piece of code needs to serve a million people, not every piece of code needs to be sold to google, sometimes you just need code to do a simple occasional job and not change every couple of years.
I don’t bother with python as you get into a horrendous mess with pip breaking and the v2/v3 issue.
Not every piece of code needs to serve a million people, not every piece of code needs to be sold to google, sometimes you just need code to do a simple occasional job and not change every couple of years.
The Python v2/v3 "issue" has been a non-issue for years now. If you're writing code to do a simple occasional job, Python is perfectly suited to that.
So is perl, and tcl and shell and JavaScript and PHP. For a "simple occasional job" the right tool is the one you know best (or the organization knows best).
Python is fully on v3 now. It was a terrible transition, but it's done.
Hahaha no. Much of our code is still v2, with no hint of a transition happening any time soon. It's mostly in maintenance mode.
Quick edit: To sibling comment's point, we're not a tech company, so it's very difficult to get this type of work done. It pretty much only happens on new development (where we are using python3), but that new development doesn't replace the old code.
Quick edit: To sibling comment's point, we're not a tech company, so it's very difficult to get this type of work done. It pretty much only happens on new development (where we are using python3), but that new development doesn't replace the old code.
Python 2 just reached end-of-life with the last-ever update arriving in October this year. So you better get moving soon if your code isn't completely air gapped.
https://adtmag.com/articles/2020/01/09/python-2-end-of-life....
There are current three outstanding CVEs for the latest version of Python 2. Hopefully, they'll be patched up in the upcoming release, but good luck after that.
https://www.cvedetails.com/vulnerability-list/vendor_id-1021...
https://adtmag.com/articles/2020/01/09/python-2-end-of-life....
There are current three outstanding CVEs for the latest version of Python 2. Hopefully, they'll be patched up in the upcoming release, but good luck after that.
https://www.cvedetails.com/vulnerability-list/vendor_id-1021...
Quick search to do something on the web and there’s a strong chance it will be python2.
Pip install? Or pip3 install? Who knows, whatever you do don’t follow the instructions s to upgrade pip as that breaks Debian and Ubuntu installs. Cpan was always a bit ropey but never this bad.
Pip install? Or pip3 install? Who knows, whatever you do don’t follow the instructions s to upgrade pip as that breaks Debian and Ubuntu installs. Cpan was always a bit ropey but never this bad.
This is true some places, but it's not true everywhere. It's just that the places stuck on Python 2 often have other disconnects that make them "invisible" on the Internet.
Not having any practical need for a “Perl version manager” as other languages have (shit, it’s even useful with Go) is an underrated benefit of choosing a language as stable as Perl. Version? What is your distro 30 years old? Just run it!
I've written many shell scripts.
Trust me, /bin/sh is not a stable, non-moving target. Not even on GNU/Linux. Go further afield and there are a great many quirks.
Even on Linux I've encounted four major flavours of /bin/sh: Dash, Bash, Ash and Msh.
The available variable interpolation syntaxes vary considerably. The only portable way to do most string things tend to use combinations of 'echo' or 'printf' and 'sed', and even those aren't portable without some platform detection. Something as simple as adding the right number of backslashes to a command, for example to quote a command given to SSH, is tricky in shell and quite version dependent.
Bash isn't a non-moving target either; I've had Bash scripts break when moved from one Linux distro to another, due solely to different behaviours of different Bash versions.
Some of the things Autoconf does to workaround /bin/sh differences are quite exciting.
If you consider /bin/sh scripting to include the behaviour of commands run from it, which you probably should, the situation is much worse. Very standard things like 'ls', 'echo', 'cp' vary across platforms in meaningful ways.
In comparison, Perl is much more consistent across platforms and versions. If it does something in one version on any platform, it almost always does exactly the same in any later version on every platform.
Trust me, /bin/sh is not a stable, non-moving target. Not even on GNU/Linux. Go further afield and there are a great many quirks.
Even on Linux I've encounted four major flavours of /bin/sh: Dash, Bash, Ash and Msh.
The available variable interpolation syntaxes vary considerably. The only portable way to do most string things tend to use combinations of 'echo' or 'printf' and 'sed', and even those aren't portable without some platform detection. Something as simple as adding the right number of backslashes to a command, for example to quote a command given to SSH, is tricky in shell and quite version dependent.
Bash isn't a non-moving target either; I've had Bash scripts break when moved from one Linux distro to another, due solely to different behaviours of different Bash versions.
Some of the things Autoconf does to workaround /bin/sh differences are quite exciting.
If you consider /bin/sh scripting to include the behaviour of commands run from it, which you probably should, the situation is much worse. Very standard things like 'ls', 'echo', 'cp' vary across platforms in meaningful ways.
In comparison, Perl is much more consistent across platforms and versions. If it does something in one version on any platform, it almost always does exactly the same in any later version on every platform.
You make a really good argument. Especially the external binaries part convinces me that shell is much more on the facetious end of that response spectrum.
I would argue that it is unfair to compare different implementations of shell, though. I think it's fair to compare across versions of bash, for example, but disingenuous to compare, e.g., Dash, Bash, Ash, and Msh. If, for example, Dash is my target, then I should call and install Dash. For this reason, it was probably a poor idea for me to call out /bin/sh, specifically, as custom dictates that this is, in fact, a different program in different environments.
I would argue that it is unfair to compare different implementations of shell, though. I think it's fair to compare across versions of bash, for example, but disingenuous to compare, e.g., Dash, Bash, Ash, and Msh. If, for example, Dash is my target, then I should call and install Dash. For this reason, it was probably a poor idea for me to call out /bin/sh, specifically, as custom dictates that this is, in fact, a different program in different environments.
This is the reason https://metacpan.org/pod/ExtUtils::Command exists.
LuaJIT has been stable for several years, and has IMHO a low chance of making major breaking changes, because it includes thousands of lines of code in seven different assembly languages, plus the lead developer seems to be burned out with big changes and is just keeping the lights on (2.1 has been beta3 for a long time). Nonetheless it does have eyeballs on it. It's also easy and fast.
One issue is that it has diverged from Lua but still shares the same name. Mainstream Lua will probably continue to be a rapidly moving target.
One issue is that it has diverged from Lua but still shares the same name. Mainstream Lua will probably continue to be a rapidly moving target.
Perl 5. In what way do you think it won't continue to solve any needs just as it did before. It's obvious someone will support it, and it's not like "this will rob Perl 5 of new people and feature development" has been valid for a decade (there isn't much in the way of new feature development, it's all strangled by backwards compatibility), and it isn't drawing new people.
For the hundreds of thousands of lines of Perl 5 code at work, I expect we'll still be running Perl 5 a decade from now, and it will still be supported in maint mode by someone, if not the official Perl devs (but probably them, I suspect some will be fine just doing big fixes for the old code base).
For any new Perl project/environment, I'll just use Perl 7.
For the hundreds of thousands of lines of Perl 5 code at work, I expect we'll still be running Perl 5 a decade from now, and it will still be supported in maint mode by someone, if not the official Perl devs (but probably them, I suspect some will be fine just doing big fixes for the old code base).
For any new Perl project/environment, I'll just use Perl 7.
Perl 5 has been declared dead before, I don't think it will die that easily :-)
Given that 95% of CPAN supports a 15 year old version of Perl (and even Mojo supports an 8 years old version), I don't think the ecosystem is going to drop it any time soon.
Given that 95% of CPAN supports a 15 year old version of Perl (and even Mojo supports an 8 years old version), I don't think the ecosystem is going to drop it any time soon.
How critical is the "scripting" aspect for you? For throwaway things where compatibility doesn't matter, I'll still use Python for quick prototypes. For almost anything else, Rust or Go or C have pretty strong cultures of backwards-compatibility.
Some which spring to mind: bash/dash/csh/ksh/etc., es, scsh, Lua, Rexx, (Chez) Scheme, Tcl, (SWI) Prolog, (GNU) Smalltalk, (GNU) Awk, Dylan, Io, (GNU) FORTH, (CMU) Common Lisp, J, ...
python3. Seriously.
I second that. Perl was my go to language, scrips, spreadsheets quick tests. Python3 does it now for me. The hardest thing to change was the one liners, but getting rid of that habit actually forced me to store more things in source instead of 500k lines shell history
[deleted]
[deleted]
Exactly. "7.0 doesn't aim to bring new features, it doesn't enable us to do anything that isn't possible without it (other than not writing that guard). Instead, it aims to change perl culture as we know it. The whole point of perl7 is radically choosing approachability over stability."
Breaking back compat without any new features on the horizon to justify them is not only ridiculous, it's suicide. They even broke back compat in 5.30 with the change of attribs on subs, which is heavily used outside of perl5, but not at all within. Totally unjustifiable.
Breaking back compat without any new features on the horizon to justify them is not only ridiculous, it's suicide. They even broke back compat in 5.30 with the change of attribs on subs, which is heavily used outside of perl5, but not at all within. Totally unjustifiable.
> Breaking back compat without any new features on the horizon to justify them is not only ridiculous, it's suicide.
I disagree. EmberJS is a great example of this philosophy done right. Major releases of Ember typically have no new features, they just break backwards compatibility in favor of more efficient ways to do things. This "sets the stage" for features that get added in minor releases. So when Ember releases a new major, you typically don't have to upgrade to it if you don't want the new features. But it's released so you can measure the level of effort as well as the impact the upgrade would have on your codebase. Contrast this with the way Ruby on Rails releases new major versions, with one giant release every couple years that either breaks compatibility, causes performance/cognitive issues, or some combination of the two.
In my opinion, major versions shouldn't have new features. The way Ember gets away with this is by sometimes releasing two versions simultaneously, a major "X.0.0" version for upgrading apps to measure the level of effort, and a minor "X.1.0" for new apps. Want to start a new app? Choose the first minor. Want to upgrade your old app? Choose the major.
I disagree. EmberJS is a great example of this philosophy done right. Major releases of Ember typically have no new features, they just break backwards compatibility in favor of more efficient ways to do things. This "sets the stage" for features that get added in minor releases. So when Ember releases a new major, you typically don't have to upgrade to it if you don't want the new features. But it's released so you can measure the level of effort as well as the impact the upgrade would have on your codebase. Contrast this with the way Ruby on Rails releases new major versions, with one giant release every couple years that either breaks compatibility, causes performance/cognitive issues, or some combination of the two.
In my opinion, major versions shouldn't have new features. The way Ember gets away with this is by sometimes releasing two versions simultaneously, a major "X.0.0" version for upgrading apps to measure the level of effort, and a minor "X.1.0" for new apps. Want to start a new app? Choose the first minor. Want to upgrade your old app? Choose the major.
I am not sure one can compare some JS framework with a language that was already 8 years old when JS as a language appeared. By the time JS was invented, there was already legacy perl code in production that needed to be maintained.
I don't see how that's relevant to software project management. The ways we release software and plan out roadmaps don't really have much to do with what language or framework the software was made in. Just because Ember is "some JS framework" doesn't mean it has no good ideas.
To me it's really not about whether it's a good idea or not. What works for an 8-year-old project that has always done it that way, may not work for a 33-year-old project which has never done it that way. The latest perl will run a huge chunk of the perl 1.0 test suite unmodified. That's a long history of backwards compatibility. This sudden change in focus and project-management may really backfire on them.
> Just because Ember is "some JS framework" doesn't mean it has no good ideas.
No, but time-scales matter. A good idea in a notoriously short lived ecosystem is not necessarily transferable to an environment in which one has to maintain 20 or 30 year old, mostly write-only code.
No, but time-scales matter. A good idea in a notoriously short lived ecosystem is not necessarily transferable to an environment in which one has to maintain 20 or 30 year old, mostly write-only code.
I don't quite understand this point. Perl has a major version, Perl 5. They want to offer a new major version, Perl 7, now. If Ember has already release a couple of new major versions, then why not learn from it? Maybe the Ember approach doesn't fit Perl, but without taking a look we won't know.
Also, based on the GP, it seems like Perl is planning something similar to what Ember has been doing: They are planning for Perl 7 to offer no new features, just change behavior. Then users can take their Perl 5 software and try it out with Perl 7 to see how much work it is to upgrade. Or they comb the source code to look for constructs that are deprecated.
Also, based on the GP, it seems like Perl is planning something similar to what Ember has been doing: They are planning for Perl 7 to offer no new features, just change behavior. Then users can take their Perl 5 software and try it out with Perl 7 to see how much work it is to upgrade. Or they comb the source code to look for constructs that are deprecated.
Putting Perl aside for a bit, I don’t quite understand the benefit of the Ember strategy you described. If I have existing code that uses Ember x-1 when x.0.0 and x.1.0 are released, what is my reason for scoping the upgrade with x.0.0 vs x.1.0? If I don’t want to implement the new features, couldn’t I still update to x.1.0 without using anything new calls?
similar strategy is for Symfony in PHP for major versions and it works well. For example next major version 6.0 will have the same features as 5.4 version with removed BC layer (deprecations etc.). This allows for smoother upgrades. You just fix all deprecations and then You can upgrade major version without stress
Much of the problem is that people see things like Perl or Python as holy grails that must not be changed or questioned. This stance mainly comes from these languages having been installed by default on almost all Unix platforms for the past 25 years. That's quite a long time to bludgeon people into thinking that these things are sacred and fixed.
Computerists should not be afraid to try something new at every turn, and then reject that something if it does not measure up. In the short run, change is often scary, but in the long run it is the only way to survive.
Computerists should not be afraid to try something new at every turn, and then reject that something if it does not measure up. In the short run, change is often scary, but in the long run it is the only way to survive.
I wonder if Perl 8 will also be a fork of Perl 5.
a similar argument is going on in c++ community - whether to value stability or performance.
one thing that always struck me is that the number of developers of X language is some factor times the number of developers at the point in time when it first had a strong community. if that factor is greater than 2, and it usually is, then to me dividing the language into two distinct dialects with different values makes sense.
one thing that always struck me is that the number of developers of X language is some factor times the number of developers at the point in time when it first had a strong community. if that factor is greater than 2, and it usually is, then to me dividing the language into two distinct dialects with different values makes sense.
Perhaps spreading out the breaking changes as PHP has done from 4 through 7.
As somebody who used PHP through that transition, I have to say that the 5-7 (skipping 6) transition was especially well handled from my perspective. There was certainly breakage, but the amount of things you had to fix was relatively small.
https://www.php.net/manual/en/migration70.incompatible.php
It was really easy to write code that worked in both 5 and 7. Most of my time was spent waiting for dependencies or frameworks to make the same jump.
Then again, I suppose PHP developers had the hindsight of Python 3 and Perl 6 as a gigantic warning klaxon of what not to do.
https://www.php.net/manual/en/migration70.incompatible.php
It was really easy to write code that worked in both 5 and 7. Most of my time was spent waiting for dependencies or frameworks to make the same jump.
Then again, I suppose PHP developers had the hindsight of Python 3 and Perl 6 as a gigantic warning klaxon of what not to do.
One thing specific to C++ is that the main point of discussion isn't necessarily about the language itself, instead it is about breaking the ABI or not moving forward. Breaking the ABI would allow for significant performance improvements, but that would require a huge amount of libraries to be recompiled, which is something a lot of vendors don't want and sometime cannot because sources aren't available anymore.
What about something like this? https://devblogs.microsoft.com/oldnewthing/20040108-00/?p=41...
Which kind of greenfield projects would the perl community like to claim? Is there anything it's particularly suited for?
If I understand right, all they are doing is changing the per-script, per-module defaults to enable current language features, instead of having most features since about 2005 disabled by default.
Perl5 has a very strong position on backward compatibility. Even when they change behaviour or add new syntax, that's disabled by default unless a script or module explicitly asks for the new behaviour.
Each significant feature can be switched off or on per module. Even if the main program turns on features, they remain off for the modules used by the main program.
So as far as I can tell, the proposal is just to change this default, so that modern Perl5 features are available to new code by default, instead of having to be explicitly requested, and there's no radical change or incompatibility planned for v7.
That's a change of compatibility-first culture. It means scripts which don't specify what they do and don't want will indeed break with newer versions, occasionally. However Perl5 changes quite slowly, and it's unusual for something new to break something old anyway.
But it should be easy for scripts to specify what they want.
If there's a "no v7" directive that should be enough at the start of any script or module that wants to keep working while being insulated from future changes. That's not much different, in practice, than what they already have to do to ask for features they do use.
Another idea would be to have two search path directories, with different defaults in each, and modules install into the appropriate one according to module metadata. This would allow existing, old modules to carry on working in v7.
Perl5 has a very strong position on backward compatibility. Even when they change behaviour or add new syntax, that's disabled by default unless a script or module explicitly asks for the new behaviour.
Each significant feature can be switched off or on per module. Even if the main program turns on features, they remain off for the modules used by the main program.
So as far as I can tell, the proposal is just to change this default, so that modern Perl5 features are available to new code by default, instead of having to be explicitly requested, and there's no radical change or incompatibility planned for v7.
That's a change of compatibility-first culture. It means scripts which don't specify what they do and don't want will indeed break with newer versions, occasionally. However Perl5 changes quite slowly, and it's unusual for something new to break something old anyway.
But it should be easy for scripts to specify what they want.
If there's a "no v7" directive that should be enough at the start of any script or module that wants to keep working while being insulated from future changes. That's not much different, in practice, than what they already have to do to ask for features they do use.
Another idea would be to have two search path directories, with different defaults in each, and modules install into the appropriate one according to module metadata. This would allow existing, old modules to carry on working in v7.
I really don't get any of this. Here's the full picture: Larry Wall mostly gave up on Perl 5 in 2000 and announced the next release would be "Perl 6". A few small updates happened to perl 5 up until 2002. Larry started working on Perl 6, forever leaving perl 5. Perl 5 goes stagnant for 5 years, meaning it had no updates released for 5 years. During this time, droves of people picked up python. Perl 6 was no where near complete in 2007, and a small team of devs pushed out perl "5.10" after a 5 year hiatus.
Perl 6 was finally released in ~2018 but by this time no one cared. The perl 6 team feels because of the name 'perl', people aren't adopting this new language, so they change the name. And now a year later, the small perl 5 team is wanting to take perl into the modern age by breaking backwards compatibility. It makes no sense at all, that was the job of perl 6.
It would no different if I started complaining about python 2 not getting any updates and then making a plan to better improve its parser and object model and break backwards compatibility and bring it into the modern age. Python 3 already did that, so like what the heck are you doing???
And then the comments from the perl 7 supporters... saying things like we can either "fight or die" or doing nothing is "certain death" but the alternative is "uncertain hope". I just don't see the point in fighting for something the original author of gave up on over 20 YEARS ago.
I've stated my points [0] before on how companies that stick with perl 5 do so at their own demise. They get cultured into a train of thought where updating software is seen as bad and unhealthy. And if they are a consultancy, their downstream customers also get cultured in to never having to worry about "updates" and/or paying for updates. So then long term contracts with said customer only take into account the cost of feature enhancements instead of "maintenance". So then it becomes impossible to move either consultancy or customer off of the "perl platform" because going to something like django, while a big cost in its own right, would involve a different long term contract that would require paid support and downtime for future django updates/releases. Never mind that finding devs would be easier (and probably cheaper), and the fact that django gets regular security audits and has a much larger plugin/library support ecosystem.
Anyway, to each their own. And godspeed to the perlings out there, I just don't see how any of this is worth it...
[0]:https://news.ycombinator.com/item?id=23633478
Perl 6 was finally released in ~2018 but by this time no one cared. The perl 6 team feels because of the name 'perl', people aren't adopting this new language, so they change the name. And now a year later, the small perl 5 team is wanting to take perl into the modern age by breaking backwards compatibility. It makes no sense at all, that was the job of perl 6.
It would no different if I started complaining about python 2 not getting any updates and then making a plan to better improve its parser and object model and break backwards compatibility and bring it into the modern age. Python 3 already did that, so like what the heck are you doing???
And then the comments from the perl 7 supporters... saying things like we can either "fight or die" or doing nothing is "certain death" but the alternative is "uncertain hope". I just don't see the point in fighting for something the original author of gave up on over 20 YEARS ago.
I've stated my points [0] before on how companies that stick with perl 5 do so at their own demise. They get cultured into a train of thought where updating software is seen as bad and unhealthy. And if they are a consultancy, their downstream customers also get cultured in to never having to worry about "updates" and/or paying for updates. So then long term contracts with said customer only take into account the cost of feature enhancements instead of "maintenance". So then it becomes impossible to move either consultancy or customer off of the "perl platform" because going to something like django, while a big cost in its own right, would involve a different long term contract that would require paid support and downtime for future django updates/releases. Never mind that finding devs would be easier (and probably cheaper), and the fact that django gets regular security audits and has a much larger plugin/library support ecosystem.
Anyway, to each their own. And godspeed to the perlings out there, I just don't see how any of this is worth it...
[0]:https://news.ycombinator.com/item?id=23633478
Perl does have a fair few quirks but those that know it are probably content for it to stay the way it is and those who don't like it have probably moved to another language.
Personally, I don't like a major version of a programming language making major breaking changes because upgrading a programming language is not at all like upgrading an app.
Would it be so bad of them just to keep Perl as it is and imagine the 'new shiny' and give that a new name - maybe Porl or something?
Personally, I don't like a major version of a programming language making major breaking changes because upgrading a programming language is not at all like upgrading an app.
Would it be so bad of them just to keep Perl as it is and imagine the 'new shiny' and give that a new name - maybe Porl or something?
I mean they already tried that with Raku (Perl6) and it didn't gain the adoption they wanted.
I am honestly disappointed, I think Raku is a much nicer language than Perl 5 or 7
And I really wish, if those working on Perl 5 would have switched to Raku, but sadly i think CPAN for Perl 5/7, have a lot more activity than the equivalent at Raku
Most new and modern languages are Compiled, Functional or targeting the JVM or .Net frameworks
Raku is I think the last and only modern scripting language , it could have used the helping hand of the Perl 5/7 community
And I really wish, if those working on Perl 5 would have switched to Raku, but sadly i think CPAN for Perl 5/7, have a lot more activity than the equivalent at Raku
Most new and modern languages are Compiled, Functional or targeting the JVM or .Net frameworks
Raku is I think the last and only modern scripting language , it could have used the helping hand of the Perl 5/7 community
There is a lot of Perl 5 code around though. Improving 5 (in a backwards compatible way) therefore provides a lot of value.
But a Perl 7 which is not focused on retaining backwards compatibility with 5 is worst of both worlds. Existing code bases will not upgrade, and nobody will start a green field project in it when Raku (not to mention Python, Ruby etc) is available. It would be dead in the water.
But a Perl 7 which is not focused on retaining backwards compatibility with 5 is worst of both worlds. Existing code bases will not upgrade, and nobody will start a green field project in it when Raku (not to mention Python, Ruby etc) is available. It would be dead in the water.
Isn't Python typically considered a scripting language, and usually ranked as at least top 3 in popularity?
Yes, but the way i see it, Raku (Perl6) was a complete rewrite of Perl .. was a radical change (rational numbers, grammar, multimethods, ...)
Python 3, is in my opinion more of an incremental and conservative change
Python 3, is in my opinion more of an incremental and conservative change
Raku is JIT-compiled, same as JVM/.net languages.
And python and javascript and ruby and lua and...
And python and javascript and ruby and lua and...
Clojure and F#, have some complexity that you wont find in Raku, try installing all 3 and run a simple script
Clojure, you will need boot or leiningen , or use the new command line tools which are not supported on windows F#, you will install dotnet core and will have to learn about the differend SDKs and compatibility differences between OSes Next try to find, install use package, its a lot less obvious how to do this compared to what I call a pure scripting language like Raku
And compared to Ruby and Python, I think Raku have more modern features , gradual typing, rational number, grammars, unicode operators etc ..
Raku is one very few pure scripting language where innovation is still happening
Clojure, you will need boot or leiningen , or use the new command line tools which are not supported on windows F#, you will install dotnet core and will have to learn about the differend SDKs and compatibility differences between OSes Next try to find, install use package, its a lot less obvious how to do this compared to what I call a pure scripting language like Raku
And compared to Ruby and Python, I think Raku have more modern features , gradual typing, rational number, grammars, unicode operators etc ..
Raku is one very few pure scripting language where innovation is still happening
[deleted]
Expressiveness +
Extensibility +
Stability
Sounds like excellent values for a programming language.
I'm interested to hear what the top three values for Perl 7 are?
Exciting times for Perl!
Sounds like excellent values for a programming language.
I'm interested to hear what the top three values for Perl 7 are?
Exciting times for Perl!
what happened to perl6? I'm confused :)
They renamed it to Raku, the renamed have two benefits in minds
1. Reintroduce Perl 6 (Raku) as a completely new language, since some thought that being linked to Perl prevented adoption
2. Open the road for Perl 5 to evolve and add features, many people in the Perl 5 community thought that Perl 6 prevented Perl 5 from growing
In Summary, the sentiment was, Perl 5 and Perl 6 are two different languages each with its own roadmap, but that the name gave the impression they are one, and prevented both from evolving
1. Reintroduce Perl 6 (Raku) as a completely new language, since some thought that being linked to Perl prevented adoption
2. Open the road for Perl 5 to evolve and add features, many people in the Perl 5 community thought that Perl 6 prevented Perl 5 from growing
In Summary, the sentiment was, Perl 5 and Perl 6 are two different languages each with its own roadmap, but that the name gave the impression they are one, and prevented both from evolving
cheers, TIL :)
Perl6 became Raku, a whole different language, something that should have happened since the very beginning instead of putting on a totally different project the label "Perl" and thus funneling in a truckload of FUD that only harmed the language.
Perl7 is as important as Rocky 7 or Terminator 7.
Love to see the Perl team discussing these issues in such a thoughtful way. Over the years I have learned to value stability and backwards compatibility, through hard lessons (which were often quite expensive to my employer). But no one value is good or bad, per se, rather they should be selected carefully: and that is the point I took away from this article.
I always wondered what the trolls on slashdot posted about Tom Christiansen when he died. The posts were all deleted.
Huh?
Last I heard, Tom Christiansen is still alive. And I'm not sure what the connection is, other than that he's done a lot of work with perl.
Last I heard, Tom Christiansen is still alive. And I'm not sure what the connection is, other than that he's done a lot of work with perl.
nintendo1889 is clearly a confused time traveler. The posts haven't been deleted. They just haven't been made yet.
I believe he's talking about the thread when W Richard Stevens died.
What happened? Stevens had some kind of hate club? Why?
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.