SawyerX’s keynote making this announcement laid out more of the rationale, how Perl 5.32 today begins reading a file as the perl of 20 years ago, then you have all the boilerplate bringing your into the modern world, and what burden that puts on newcomers.
Most things today will run okay under an interpreter that has all this on by default, but if you really, really want to stick to “no strict” by default it will be a one line change to get back. I don’t think this is going to be that burdensome for things like distros that have perl in the base for support scripts - I mean, hopefully they’re already strict safe.
A point I found interesting is that with this Perl (5) finally has a roadmap other than “let’s keep things as-is”. There was a hint that Cor, the new object system, may get included in one of the new releases as the object system to be used.
Exciting times. Raku is cool and all, but Perl (5) has this peculiar elegance to it that I haven’t quite seen anywhere else. I’m happy to see the edges smoothed out.
A point I found interesting is that with this Perl (5) finally has a roadmap other than “let’s keep things as-is”.
There’s been one of those for about ten years, to be fair. 2000-2010 was kind of stagnant, development-wise, but with the 5.12 series in 2010 we got a yearly release cadence, a deprecation policy, a mechanism for ‘experimental’ features, a new policy on what goes in core, and more focus on new features to make the language nicer to use. Sure, the pace of development hasn’t been blazing fast, and we do still care a lot about back-compatibility (being realistic, if new users aren’t flocking in by the millions, you should at least take care of the ones you’ve got, and their legacy apps), but it’s been a real thing.
Another thing that might not be immediately obvious to outsiders, but that’s been going on for ten years, is the outright encouragement of hacking the language from modules. Perl has always been flexible in that way, but since around 5.12 or 5.14 that’s been ramped up even more with features like keyword plugins, meaning that it’s been possible to create stuff like sub signatures and async/await as completely optional features that anyone can play with, and that can be developed outside of core, and then propose them for adoption as core features down the line.
There’s been one of those for about ten years, to be fair
Yes, good point. However, from my perspective it always felt like there was no clear vision in there, other than “let’s see what we can introduce without breaking anything”, and apart from sub signatures (which are still experimental, and I remember being excited about them on YAPC::NA 2013) and the syntax extension ops you mentioned there hasn’t really been anything major on the horizon. All the stuff prototyped in module space can, technically, end up in core one day – but when’s the last time that has happened? Even the aforementioned sub signatures happened only because of one dedicated guy who wasn’t allowed to use CPAN at work so he needed to put them in core.
As 5.32 was approaching release, I had no idea if there’ll even be anything to be excited about. It’s comforting to see that there’s now a bold vision for the future. Sawyer’s talk really spoke to me – I’d like my Perl to by nice by default, rather than “I have enough years of experience to bend it into something nice, most of the time”.
Yeah, no doubt. I like it too, I don’t mind seeing a little more boldness. It’s either do that or fade out entirely. I just want to give a little credit to all the cool folks who haven’t been sitting doing nothing since 2000. This is a culmination, not a bolt from the blue.
In general I find that the Perl community has the best sense humour of all the major languages. I am not a huge Perl fan myself, but I much prefer this over the humourless Very Serious attitude of some other languages.
Well, ain’t that a thing. I admire the effort that went into Raku - it was and still is an interesting project - but the transition efforts that Ruby and Python went through showed that you can’t make too great a departure, even if you think you’ve put the mechanisms in place to smooth the path. Human factors inevitably complicate everything.
SawyerX’s keynote making this announcement laid out more of the rationale, how Perl 5.32 today begins reading a file as the perl of 20 years ago, then you have all the boilerplate bringing your into the modern world, and what burden that puts on newcomers.
Most things today will run okay under an interpreter that has all this on by default, but if you really, really want to stick to “no strict” by default it will be a one line change to get back. I don’t think this is going to be that burdensome for things like distros that have perl in the base for support scripts - I mean, hopefully they’re already strict safe.
A point I found interesting is that with this Perl (5) finally has a roadmap other than “let’s keep things as-is”. There was a hint that Cor, the new object system, may get included in one of the new releases as the object system to be used.
Exciting times. Raku is cool and all, but Perl (5) has this peculiar elegance to it that I haven’t quite seen anywhere else. I’m happy to see the edges smoothed out.
There’s been one of those for about ten years, to be fair. 2000-2010 was kind of stagnant, development-wise, but with the 5.12 series in 2010 we got a yearly release cadence, a deprecation policy, a mechanism for ‘experimental’ features, a new policy on what goes in core, and more focus on new features to make the language nicer to use. Sure, the pace of development hasn’t been blazing fast, and we do still care a lot about back-compatibility (being realistic, if new users aren’t flocking in by the millions, you should at least take care of the ones you’ve got, and their legacy apps), but it’s been a real thing.
Another thing that might not be immediately obvious to outsiders, but that’s been going on for ten years, is the outright encouragement of hacking the language from modules. Perl has always been flexible in that way, but since around 5.12 or 5.14 that’s been ramped up even more with features like keyword plugins, meaning that it’s been possible to create stuff like sub signatures and
async
/await
as completely optional features that anyone can play with, and that can be developed outside of core, and then propose them for adoption as core features down the line.Yes, good point. However, from my perspective it always felt like there was no clear vision in there, other than “let’s see what we can introduce without breaking anything”, and apart from sub signatures (which are still experimental, and I remember being excited about them on YAPC::NA 2013) and the syntax extension ops you mentioned there hasn’t really been anything major on the horizon. All the stuff prototyped in module space can, technically, end up in core one day – but when’s the last time that has happened? Even the aforementioned sub signatures happened only because of one dedicated guy who wasn’t allowed to use CPAN at work so he needed to put them in core.
As 5.32 was approaching release, I had no idea if there’ll even be anything to be excited about. It’s comforting to see that there’s now a bold vision for the future. Sawyer’s talk really spoke to me – I’d like my Perl to by nice by default, rather than “I have enough years of experience to bend it into something nice, most of the time”.
Yeah, no doubt. I like it too, I don’t mind seeing a little more boldness. It’s either do that or fade out entirely. I just want to give a little credit to all the cool folks who haven’t been sitting doing nothing since 2000. This is a culmination, not a bolt from the blue.
The video is marked as private? Will it be publicly available later?
Oh, they must have edited and reposted, I’ve updated the link.
Thanks!
🔥 🔥 🔥
I appreciated the hell out of that joke. I very nearly spit out my water onto my brand new keyboard.
In general I find that the Perl community has the best sense humour of all the major languages. I am not a huge Perl fan myself, but I much prefer this over the humourless Very Serious attitude of some other languages.
Well, ain’t that a thing. I admire the effort that went into Raku - it was and still is an interesting project - but the transition efforts that Ruby and Python went through showed that you can’t make too great a departure, even if you think you’ve put the mechanisms in place to smooth the path. Human factors inevitably complicate everything.
That’s great! One the one hand, I don’t like Perl 6’s new name, but on the other hand – a new version of Perl!