8 ms·
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 reaso
by lmiller1990 6y ago
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.
- vikramkr 6y agoI 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.
- greggyb 6y agoJust 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.
- WoodenChair 6y agoI 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.
- orev 6y agoIt 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.
- antasvara 6y agoThe 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.
- greggyb 6y agoThe 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-hand https://writingexplained.org/idiom-dictionary/bird-in-the-ha... https://en.wiktionary.org/wiki/a_bird_in_the_hand_is_worth_two_in_the_bush 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://www.phrases.org.uk/meanings/a-bird-in-the-hand.html https://grammarist.com/proverb/a-bird-in-the-hand-is-worth-two-in-the-bush/ https://grammarist.com/proverb/a-bird-in-the-hand-is-worth-t...
- throwaway2048 6y agoAnd 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.
- tyingq 6y agoAs 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.
- claydavisss 6y ago> 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.
- kbenson 6y ago> 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.
- chomp 6y agoSomething’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.
- mokus 6y agoWhat’s wrong with letting the language die?
- johannes1234321 6y agoIt'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.
- quonn 6y agoWhy 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.
- johannes1234321 6y agoYou 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.
- tyingq 6y agoI 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.
- zzz61831 6y ago> 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.
- tyingq 6y agoThere 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.
- sigzero 6y ago> 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.
- wdr1 6y agoI 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.
- alicemaz 6y agoI 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
- labster 6y agoAt 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.