5 ms·

I’ve written a nontrivial anount of Perl code in my life, admittedly almost none in the last decade. For all its obvious flaws, I always liked the language, and

I’ve written a nontrivial anount of Perl code in my life, admittedly almost none in the last decade. For all its obvious flaws, I always liked the language, and am happy to see it getting attention and moving forward. Having said that, I think this might be too fine-grained. First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing your valuable beta testers beyond that with a second line that’s entirely redundant with the first one. The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. I personally like the “edition” concept of Rust a lot better: get over with all necessary breaking changes in one swoop, but then begin a new (hopefully long) era of backwards compatibility. That makes it easier for users to maintain their code, is probably easier to implement, and also easier for users to learn, since there are fewer sets of rules. Lastly, I hope they also focus on tooling around installation. One paradoxical problem with modernizing Perl is its historic success: every variant of Linux or Unix already comes with an ancient version of it. I know many experienced Unix people hate this trend, but there’s a reason some of the most actively evolving language ecosystems install more and more of their binaries into the user’s home directory. Maybe that’s already the case for Perl, I wouldn’t know. All that said, I’m not following Perl that closely anymore. These are just some really quick observations about very complex topics. I don’t claim to know nearly as much as the people who made these decisions, and it’s great to see that things are happening.

badsectoracula 4y ago
> The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. But to use that new feature they'd need to modify their code anyway, so this isn't really an issue in practice, is it? > I personally like the “edition” concept of Rust a lot better: get over with all necessary breaking changes in one swoop, but then have a new (hopefully long) era of backwards compatibility. How is this any different from having a repeat of the python2->python3 fiasco (which, AFAIK, Perl developers are trying to avoid)? Making piecemeal (if needed) changes is much easier than having to update a ton of code and that is even more important when that code wasn't touched for a long time. EDIT (i put it here since i already got three replies on the same thing): i understand that you can mix two different files with different "editions" but it still makes it hard to update these files themselves.
- temac 4y ago
  IIRC you can mix different editions in a project, and I think backward incompatibilities are also fewer (and detected at compilation)
- gwd 4y ago
  > How is this any different from having a repeat of the python2->python3 fiasco (which, AFAIK, Perl developers are trying to avoid)? AFAIUI you can mix Rust 2015, 2018, and 2021 crates; so a developer can update their own crate to 2021, while not having to completely re-write the dependencies which are still Rust 2015. With Python 2 -> 3, my understanding was that everything had to be updated recursively. That said... > I personally like the “edition” concept of Rust a lot better: get over with all necessary breaking changes in one swoop, but then have a new (hopefully long) era of backwards compatibility. What they describe actually sounds somewhat similar: > At some point in the future, the PSC may decide that the set of features, taken together, represent a big enough step forward to justify a new baseline for Perl. If that happens, then the version will be bumped to 7.0. If this happens, Perl 7 will still be backwards compatible with Perl 5 by default – you'll have to put use v7; at the top of your code to use all the new features. Think of use v7 like Modern::Perl and similar modules. So the 'use <feature>' is going to be similar to Rust's "nightly unstable features", but actually being stable; and 'use vN' is going to be like Rust's Editions. It's just that they don't think they've accumulated enough features to release a new Edition yet.
  - codeflo 4y ago
    Your last two paragraphs describe Rust’s process differently than I would in comparison to this suggestion. First, significant new language features are introduced all the time, even in stable, all of them enabled by default (indeed, there’s no way to turn them off). Nightly’s #![feature(…)] is strictly for experimental stuff that is buggy and/or will change until stable release. I’m sure you know this, but all of those are intended to be backwards compatible! I think that’s a big difference. Incompatible changes in Rust never happen with “features” (as you know, stable doesn’t even have those), but only with “editions”. The goal of an edition is to carve out a large chunk of future design space, like introducing some keywords for planned features, or rarely, fixing really annoying inconsistencies that require a breaking change. They feel a lot more proactive (we want to do this, we need an edition) than retroactive.
kamaal 4y ago
>>I know many experienced Unix people hate this trend, but there’s a reason some of the most actively evolving language ecosystems install more and more of their binaries into the user’s home directory. The future is containers, which is basically increasingly thin images tailored to your application. These days I struggle to find Perl on many EC2 instance I work on. Its always good to have something like Perl in your installation for some quick scripting work. But most don't have Perl installed.
HelloNurse 4y ago
Users do not "want to keep getting new features"; they occasionally decide to make an effort to upgrade the Perl interpreters on their servers and personal machines because they want some new features. A "use v5.36" directive is going to be very opaque for many users, but it doesn't need to be understood to serve the purpose of determining the minimum Perl version to install in order to run a certain script very effectively.
- codeflo 4y ago
  If user = server administrator writing simple scripts, you are probably right. If user = a team of devs, I don’t agree. You often want to use new language features just to simplify a piece of code, and you don’t want confusing rules around when you can and can’t use them.
  - HelloNurse 4y ago
    What confusing rules? Given the promise of perennial backwards compatibility, the rule that if you want to use a feature you have to upgrade to the appropriate Perl version isn't confusing. Neither is keeping development environment up to date and letting Perl versions on servers lapse until you install the latest Perl version because you have new Perl scripts requiring new features, or there are urgent security fixes, or you are building a new server or container anyway.
  - cestith 4y ago
    You can't use the new feature without editing code to use the new feature. If you're editing code, bumping the version number at the top is trivial.
D13Fd 4y ago
Seems like they could just lock all of the new features behind a “use x.x” line rather than going feature-by-feature. And they could include “use latest” or similar for people who don’t care about the risk and are fine just fixing things if they break.
- sigzero 4y ago
  No, that is what they are doing. "use v7;" gets you all the new stuff and that will continue going forward. They only listed what "use v7;" is the equivalent of in the article.
Grinnz 4y ago
> First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing your valuable beta testers beyond that with a second line that’s entirely redundant with the first one. It is. "use experimental 'try';" works already. > The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. This is intentional. The largest strength of Perl is that, barring significant security-type issues, a script written in 1995 will still run with the version of Perl you've installed. If you write a script with "use v5.36", you would change that version only if you intend to modernize the script with features from a newer version, and determine that such features don't break the script. This is harder to determine for some features than others, for example applying the 'unicode_strings' feature to an existing script written without it is rather perilous.
cestith 4y ago
>> I know many experienced Unix people hate this trend, but there’s a reason some of the most actively evolving language ecosystems install more and more of their binaries into the user’s home directory. Maybe that’s already the case for Perl, I wouldn’t know. There's https://perlbrew.pl/ https://perlbrew.pl/ and there's cpanm with "use lib".
bmn__ 4y ago
> opting in to an experimental feature could be a one-liner This exists since 2013. https://metacpan.org/pod/experimental https://metacpan.org/pod/experimental > Probably not much of a problem currently, but might be if releases get more frequent. Very unlikely. Perl switched to a yearly release in 2010, it has been in use since and there is no indication for this to change. https://lwn.net/Articles/485569/#:~:text=a%20%22timeboxed%22%20release%20schedule https://lwn.net/Articles/485569/#:~:text=a%20%22timeboxed%22... > focus on tooling around installation […] install more and more of their binaries into the user’s home directory Exists. Wouldn't be Perl if one hadn't the choice between multiple solutions. https://metacpan.org/pod/local::lib https://metacpan.org/pod/local::lib https://perlbrew.pl https://perlbrew.pl https://github.com/tokuhirom/plenv https://github.com/tokuhirom/plenv https://metacpan.org/pod/perlall https://metacpan.org/pod/perlall https://metacpan.org/pod/App::plx https://metacpan.org/pod/App::plx https://github.com/stevieb9/berrybrew https://github.com/stevieb9/berrybrew > I’m not following Perl that closely anymore It is evident.
- codeflo 4y ago
  > This exists since 2013. Good to know, but maybe it’s not my fault that I assumed an official post by the Perl Steering Committee on perl.org would show the best solution. > Exists. Wouldn't be Perl if one hadn't the choice between multiple solutions. That’s great, but you might notice that you’ve given me, who is new to these approaches in Perl, exactly no information on where to start. > It is evident. Yes, I was very transparent about the extent and recency of my experience. Luckily, that combative attitude to a mostly interested/positive comment isn’t representative of the Perl community as a whole, or there really wouldn’t be any users left.
  - bmn__ 4y ago
    > I assumed an official post by the Perl Steering Committee on perl.org would show the best solution Different people have different opinions on what constitutes "best". The post author is conservative and values compatibility over conciseness. > no information on where to start If one doesn't know the difference, then likely local::lib is appropriate. It's already built into the installation tools: https://metacpan.org/pod/cpan#-I https://metacpan.org/pod/cpan#-I https://metacpan.org/pod/cpanm#-l,-local-lib https://metacpan.org/pod/cpanm#-l,-local-lib > combative attitude The assumption of me wanting to fight comes as a surprise, but you got hold of the wrong end of the stick.

badsectoracula 4y ago

> The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. But to use that new feature they'd need to modify their code anyway, so this isn't really an issue in practice, is it? > I personally like the “edition” concept of Rust a lot better: get over with all necessary breaking changes in one swoop, but then have a new (hopefully long) era of backwards compatibility. How is this any different from having a repeat of the python2->python3 fiasco (which, AFAIK, Perl developers are trying to avoid)? Making piecemeal (if needed) changes is much easier than having to update a ton of code and that is even more important when that code wasn't touched for a long time. EDIT (i put it here since i already got three replies on the same thing): i understand that you can mix two different files with different "editions" but it still makes it hard to update these files themselves.

temac 4y ago
IIRC you can mix different editions in a project, and I think backward incompatibilities are also fewer (and detected at compilation)
gwd 4y ago
> How is this any different from having a repeat of the python2->python3 fiasco (which, AFAIK, Perl developers are trying to avoid)? AFAIUI you can mix Rust 2015, 2018, and 2021 crates; so a developer can update their own crate to 2021, while not having to completely re-write the dependencies which are still Rust 2015. With Python 2 -> 3, my understanding was that everything had to be updated recursively. That said... > I personally like the “edition” concept of Rust a lot better: get over with all necessary breaking changes in one swoop, but then have a new (hopefully long) era of backwards compatibility. What they describe actually sounds somewhat similar: > At some point in the future, the PSC may decide that the set of features, taken together, represent a big enough step forward to justify a new baseline for Perl. If that happens, then the version will be bumped to 7.0. If this happens, Perl 7 will still be backwards compatible with Perl 5 by default – you'll have to put use v7; at the top of your code to use all the new features. Think of use v7 like Modern::Perl and similar modules. So the 'use <feature>' is going to be similar to Rust's "nightly unstable features", but actually being stable; and 'use vN' is going to be like Rust's Editions. It's just that they don't think they've accumulated enough features to release a new Edition yet.
- codeflo 4y ago
  Your last two paragraphs describe Rust’s process differently than I would in comparison to this suggestion. First, significant new language features are introduced all the time, even in stable, all of them enabled by default (indeed, there’s no way to turn them off). Nightly’s #![feature(…)] is strictly for experimental stuff that is buggy and/or will change until stable release. I’m sure you know this, but all of those are intended to be backwards compatible! I think that’s a big difference. Incompatible changes in Rust never happen with “features” (as you know, stable doesn’t even have those), but only with “editions”. The goal of an edition is to carve out a large chunk of future design space, like introducing some keywords for planned features, or rarely, fixing really annoying inconsistencies that require a breaking change. They feel a lot more proactive (we want to do this, we need an edition) than retroactive.

kamaal 4y ago

>>I know many experienced Unix people hate this trend, but there’s a reason some of the most actively evolving language ecosystems install more and more of their binaries into the user’s home directory. The future is containers, which is basically increasingly thin images tailored to your application. These days I struggle to find Perl on many EC2 instance I work on. Its always good to have something like Perl in your installation for some quick scripting work. But most don't have Perl installed.

HelloNurse 4y ago

Users do not "want to keep getting new features"; they occasionally decide to make an effort to upgrade the Perl interpreters on their servers and personal machines because they want some new features. A "use v5.36" directive is going to be very opaque for many users, but it doesn't need to be understood to serve the purpose of determining the minimum Perl version to install in order to run a certain script very effectively.

codeflo 4y ago
If user = server administrator writing simple scripts, you are probably right. If user = a team of devs, I don’t agree. You often want to use new language features just to simplify a piece of code, and you don’t want confusing rules around when you can and can’t use them.
- HelloNurse 4y ago
  What confusing rules? Given the promise of perennial backwards compatibility, the rule that if you want to use a feature you have to upgrade to the appropriate Perl version isn't confusing. Neither is keeping development environment up to date and letting Perl versions on servers lapse until you install the latest Perl version because you have new Perl scripts requiring new features, or there are urgent security fixes, or you are building a new server or container anyway.
- cestith 4y ago
  You can't use the new feature without editing code to use the new feature. If you're editing code, bumping the version number at the top is trivial.

D13Fd 4y ago

Seems like they could just lock all of the new features behind a “use x.x” line rather than going feature-by-feature. And they could include “use latest” or similar for people who don’t care about the risk and are fine just fixing things if they break.

sigzero 4y ago
No, that is what they are doing. "use v7;" gets you all the new stuff and that will continue going forward. They only listed what "use v7;" is the equivalent of in the article.

Grinnz 4y ago

> First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing your valuable beta testers beyond that with a second line that’s entirely redundant with the first one. It is. "use experimental 'try';" works already. > The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. This is intentional. The largest strength of Perl is that, barring significant security-type issues, a script written in 1995 will still run with the version of Perl you've installed. If you write a script with "use v5.36", you would change that version only if you intend to modernize the script with features from a newer version, and determine that such features don't break the script. This is harder to determine for some features than others, for example applying the 'unicode_strings' feature to an existing script written without it is rather perilous.

cestith 4y ago

>> I know many experienced Unix people hate this trend, but there’s a reason some of the most actively evolving language ecosystems install more and more of their binaries into the user’s home directory. Maybe that’s already the case for Perl, I wouldn’t know. There's https://perlbrew.pl/ https://perlbrew.pl/ and there's cpanm with "use lib".

bmn__ 4y ago

> opting in to an experimental feature could be a one-liner This exists since 2013. https://metacpan.org/pod/experimental https://metacpan.org/pod/experimental > Probably not much of a problem currently, but might be if releases get more frequent. Very unlikely. Perl switched to a yearly release in 2010, it has been in use since and there is no indication for this to change. https://lwn.net/Articles/485569/#:~:text=a%20%22timeboxed%22%20release%20schedule https://lwn.net/Articles/485569/#:~:text=a%20%22timeboxed%22... > focus on tooling around installation […] install more and more of their binaries into the user’s home directory Exists. Wouldn't be Perl if one hadn't the choice between multiple solutions. https://metacpan.org/pod/local::lib https://metacpan.org/pod/local::lib https://perlbrew.pl https://perlbrew.pl https://github.com/tokuhirom/plenv https://github.com/tokuhirom/plenv https://metacpan.org/pod/perlall https://metacpan.org/pod/perlall https://metacpan.org/pod/App::plx https://metacpan.org/pod/App::plx https://github.com/stevieb9/berrybrew https://github.com/stevieb9/berrybrew > I’m not following Perl that closely anymore It is evident.

codeflo 4y ago
> This exists since 2013. Good to know, but maybe it’s not my fault that I assumed an official post by the Perl Steering Committee on perl.org would show the best solution. > Exists. Wouldn't be Perl if one hadn't the choice between multiple solutions. That’s great, but you might notice that you’ve given me, who is new to these approaches in Perl, exactly no information on where to start. > It is evident. Yes, I was very transparent about the extent and recency of my experience. Luckily, that combative attitude to a mostly interested/positive comment isn’t representative of the Perl community as a whole, or there really wouldn’t be any users left.
- bmn__ 4y ago
  > I assumed an official post by the Perl Steering Committee on perl.org would show the best solution Different people have different opinions on what constitutes "best". The post author is conservative and values compatibility over conciseness. > no information on where to start If one doesn't know the difference, then likely local::lib is appropriate. It's already built into the installation tools: https://metacpan.org/pod/cpan#-I https://metacpan.org/pod/cpan#-I https://metacpan.org/pod/cpanm#-l,-local-lib https://metacpan.org/pod/cpanm#-l,-local-lib > combative attitude The assumption of me wanting to fight comes as a surprise, but you got hold of the wrong end of the stick.