34 ms·

Perl 5.18.0 is now available

128 points by yko 13y ago

btipling 13y ago
The dynamic scoping in Perl seems a bit troublesome to me. Maybe even a security issue. Can you prevent functions you call from accessing variables in your scope? Do you have to somehow sanitize your scope if this is an issue? Seems a little bit worrying. With the exception of closures inside nested functions, I wish functions just had their own scope and if you want them to have anything else, just pass it in.
- rmah 13y ago
  When I first started using perl, I too, worried about this and other similar issues. But after 10+ years of using perl, I've never -- not once -- actually run into this problem in the real world.
  - btilly 13y ago
    I have not been so lucky. I've had to submit patches to CPAN modules because their use of $_ broke dynamically scoped access to $_.
- btilly 13y ago
  This is why wise Perl programmers turn on use strict, and then declare variables with my. Now attempting to dynamically scope stuff is a compilation error. (Except for some built in variables, like $_. Which you don't use in real programs.) This has been standard advice since the last millennium. But you can't change it without breaking backwards compatibility. That said, I do have several good uses for local. But not normal ones. My favorite is to use local to dynamically scope entries in a hash. I wind up using this every year or two to put in an automatic check to catch infinite recursion.
  - snaky 13y ago
    >variables, like $_. Which you don't use in real programs Oh really? What's wrong with $_ and since when it is?
    - sliverstorm 13y ago
      It's kind of obtuse. If you have to type out "$_", you might as well declare it and give it a good name. I personally have no issues doing: foreach @array { chomp; print; } But as soon as I have to type "$_" I make a real variable.
      - snaky 13y ago
        What's wrong to type $_ if you want to print "`$_'\n" in your example? Etc. I don't see any problem with that as $_ is clearly states that's a loop counter. And let's don't even talk about map/grep/sort and schwartzian transform.
        pfortuny 13y ago
        I don't think he sees that as a Problem. Only he thinks using it explicitly is not to his taste. I have a similar attitude: make it explicitly a new var if it is going to appear in the code. Your example is perfectly OK. TIMTOWTDI, really.
      - singingfish 13y ago
        $_ is pronounced "it" and should only be used in small blocks of code. This is in much the same way that in a paragraph of text "it" should only be used for transitory sentences on the same topic as the previous one.
    - btilly 13y ago
      The problem is that $_ is global and always in package main. A specific problem that fixed this in my memory was a bug in my co-worker's code which boiled down to his looping over an array with $_, then calling a function in his loop that was in a CPAN library that assigned to $_. The result was that he wiped out his whole array. Whenever you are calling out to code that someone else wrote, you don't know if issues like that could exist, and therefore it isn't safe to use $_. Conversely if you're writing code that someone else will call, be a good citizen and don't assign to $_ either implicitly or explicitly.
  - jerf 13y ago
    I like local for two big uses: One, in unit testing, it's a cheap way to completely mock out a function within some scope. I know there's various test methods for that, but frankly local'ing a glob is so easy both to use and to make do exactly what I need that it's often still easier than even invoking the library. Second, I love it for security-related stuff where I really don't want something to escape a scope. I have a value that represents the current user I am processing a request for, which is used for security checks, and by local'ing the variable in the context of the handler, I can be very confident that it absolutely, positively will not escape into the next request. It also turns out to mean that if you're in a code base that has some unfortunate "global" variables, that local lets you turn them into much less "global" variables, as you can local them with confidence about how it won't escape out of scope. Of course, the better solution is to not do that, or to fix it, but we don't live in a perfect world....
- chromatic 13y ago
  Can you prevent functions you call from accessing variables in your scope? Perl's access control model uses a metaphor of polite permission. Without hardware enforcing memory protection, any memory protection at the language level is a modest barrier for the determined anyhow.
acqq 13y ago
The changes: http://search.cpan.org/~rjbs/perl/pod/perldelta.pod http://search.cpan.org/~rjbs/perl/pod/perldelta.pod
alberth 13y ago
Only 82 more minor releases until Perl 6 will be available.
- sigzero 13y ago
  Perl 5 will not ever go to Perl 6. Although you probably forgot the sarcasm tag. :)
- latk 13y ago
  Almost ;-) The current perl version is 5.018000, so that would take 982 releases until the numbering scheme breaks down. Of course, Perl v-strings can have elements of INT_MAX each, but I doubt such high numbers would ever be used, for back-compat reasons.
Su-Shee 13y ago
Perl 6 releases itself monthly for YEARS now. http://rakudo.org/how-to-get-rakudo/ http://rakudo.org/how-to-get-rakudo/ http://rakudo.org/downloads/rakudo/ http://rakudo.org/downloads/rakudo/
- chromatic 13y ago
  To be fair, so does Perl 5. Perl 5.18.0 happens to be the yearly major release. To my knowledge, Rakudo hasn't reached the point where its developers call any Star (runtime plus libraries) release a "major release" of the sort that users ought to use in the wild for a year or more.
- rmah 13y ago
  Perl 6 isn't perl.
  - mhd 13y ago
    I think there should be some kind of changing of names. For a while it looked like it's another incremental step, if a big one. Which obviously requires running two implementations in parallel for a while -- similar to Python 2 and 3, or several operating systems and distros. But right now, especially once Perl development really picked up, it might be time to "divorce" the two languages. It seems more like Algol60 vs. Algol68, or Modula-2 vs. Modula-3. Sure, there's a number in there, but it isn't just about the version of the main implementation. Having said that, kudos to the Perl team. I really like that they now release new versions pretty regularly, which is a good sign to show people that Perl5 ist still very much alive and nobody needs to hold their breath for the time being. If only I could use something more recent than 5.8 at work...
    - espadrine 13y ago
      Perl5 users won't switch to Perl6 because they're working on Perl5 code and don't want to change their habits. Non-Perl devs won't switch to Perl6 because the P word scares them. So, yes, changing the name might be a good idea. And making an enjoyable web-based tutorial.
creaktive 13y ago
perlbrew install -j 8 -v http://cpan.metacpan.org/authors/id/R/RJ/RJBS/perl-5.18.0.tar.bz2 http://cpan.metacpan.org/authors/id/R/RJ/RJBS/perl-5.18.0.ta...
prollyignored 13y ago
I was a Perl lover once. And now it seems I understand the haters. Just don't use Perl. The language seems fine, productive, even sublime at first but you will encounter some horrible design features. Just read the following, http://markmail.org/message/h2spyi5za4qheuft http://markmail.org/message/h2spyi5za4qheuft -- Perl's data structure serialization is leaky. Thought you made an int ? Whoa ... serialized as a string. http://blogs.perl.org/users/rurban/2013/02/no-indirect-considered-harmful.html#comment-370624 http://blogs.perl.org/users/rurban/2013/02/no-indirect-consi... -- A language feature causing a burnout ? Well fuck me ! That's just a tip of the iceberg. PHP, a fractal of bad design ? Perl, a quantum bomb, waiting to tick off. The Modern Perl movement is like saying "I'll close my eyes and crime ceases to exist." No best practices will save you from broken language features. The people who maintain Perl source code, are not a _fan_ of Modern Perl. They won't make "strict" the default or introduce signatures or better OOmodel. The people who proclaim "Modern Perl" won't fork. Even this release shows how clueless Perl maintainers are ! * They released a switch statement long long back * And now they mark it even as "experimental" because of the leaky "my $_" scope. Oh God ! I will never emotionally invest in another tool. EDIT: Neutral language.
- hahainternet 13y ago
  I downvoted you because of a) The poor formatting of your post as a stream of conciousness b) The condemnation of a language based on a single relatively minor bug c) The unsupported assertions and unrelated criticisms like not enabling strict by default
  - prollyignored 13y ago
    I use points as I am a bad writer. * Don't use $a, $b for variable names, affecting sort * Don't use each for iterating over hashes * Global effects of .. * next operator is dynamic sub foo() { next; #breaks while loop } while(defined (my $e = shift @items)) { # "0", 0 is false foo(); } * http://www.perl.com/doc/FMTEYEWTK/versus/perl.html http://www.perl.com/doc/FMTEYEWTK/versus/perl.html * Exception model based on $_ and $@ * print "$foo's fun!"; * `use constant` is broken * my $a, $b ... declares a global $b. Not DWIM at all. These language features are not worth the debugging time. Regarding c) I am not a fan of use strict. If the community's priority is introducing more features like "my $_" than sane exception handling, I don't want to be a part of it and I won't recommend that language to my boss or the next FOSS project. Did I mention XS bugs ?
jerf 13y ago
Can someone explain the point of the lexical subroutines? [1] In particular, I'm lost on the difference between sub outer { my $closurevar; my $inner = sub { ... use $closurevar... }; } and sub outer { my $closurevar; my sub inner { ... use $closurevar... } } (I mean this as an honest question. That said, I do hope that I'm missing something and this is more than just a syntax gloss.) [1]: http://search.cpan.org/~rjbs/perl-5.18.0/pod/perlsub.pod#Lexical_Subroutines http://search.cpan.org/~rjbs/perl-5.18.0/pod/perlsub.pod#Lex...
- latk 13y ago
  In the end, everything is syntax. In the first solution, the inner sub would be called as "$inner->()" or "&$inner()". With lexical subs, we get the much nicer syntax "inner()". This decreases the syntactic pain when structuring your code to use nested functions, thus encouraging good design. Oh, and I guess lexical subs can have prototypes, which were ignored when calling a coderef with `&` or `->()`. This allows to create really nice, but properly scoped pseudosyntax.
  - prollyignored 13y ago
    > This decreases the syntactic pain use 5.018; no warnings "experimental::lexical_subs"; use feature "lexical_subs"; Don't use perl experimental features. Not portable. Not well thought. May break horribly. "state sub creates a subroutine visible within the lexical scope in which it is declared. The subroutine is shared between calls to the outer sub." So you should be using "state sub" Or use python which has non-experimental "inner functions"
    - latk 13y ago
      You make some very good points esp. wrt verbosity. However, I don't care about portability or not using experimental features for personal or exploratory projects: stability is silver, conciseness is gold. The "state" subs are a consequent extension of the variable declaration keywords "my", "state", and "our". I can see myself using "my subs" in the future, the other possibilities have less practical use. "my subs" are proper closures, so they are not shared. But, somebody will probably write a "lexsub" pragma that does away with the "no warnings ...", and portability becomes less of an issue over the course of time, much like I can nowadays treat the features of v5.10 as given. Perl had nested functions since v5, just with akward syntax. Does Python have proper <del>variable declarations</del> closures? That is more of a dealbraker than non-experimental nested function syntax for me ;-)
will1000 13y ago
Is python 3 the new perl 6?
greyman 13y ago
Just curious: Is Larry Wall still involved in Perl development? Haven't heard from him for a long time...
- wazoox 13y ago
  He's not involved in Perl 5 development anymore AFAIK.
- sigzero 13y ago
  He is solely working on Perl 6 now.
  - colomon 13y ago
    And is fairly active there: https://github.com/TimToady https://github.com/TimToady
mpyne 13y ago
I understand why smartmatch is labeled experimental, but what's the "modern Perl" replacement for given/when? I only use it as a stupid switch statement but I don't want it breaking with Perl 5.22 either...
- jevinskie 13y ago
  I feel like I was given the impression that they wanted to get smart match "right" and not abandon it. I guess my use of smart match was a mistake. =(
deleted 13y ago
[deleted]

128 points by yko 13y ago

The dynamic scoping in Perl seems a bit troublesome to me. Maybe even a security issue. Can you prevent functions you call from accessing variables in your scope? Do you have to somehow sanitize your scope if this is an issue? Seems a little bit worrying. With the exception of closures inside nested functions, I wish functions just had their own scope and if you want them to have anything else, just pass it in.

rmah 13y ago
When I first started using perl, I too, worried about this and other similar issues. But after 10+ years of using perl, I've never -- not once -- actually run into this problem in the real world.
- btilly 13y ago
  I have not been so lucky. I've had to submit patches to CPAN modules because their use of $_ broke dynamically scoped access to $_.
btilly 13y ago
This is why wise Perl programmers turn on use strict, and then declare variables with my. Now attempting to dynamically scope stuff is a compilation error. (Except for some built in variables, like $_. Which you don't use in real programs.) This has been standard advice since the last millennium. But you can't change it without breaking backwards compatibility. That said, I do have several good uses for local. But not normal ones. My favorite is to use local to dynamically scope entries in a hash. I wind up using this every year or two to put in an automatic check to catch infinite recursion.
- snaky 13y ago
  >variables, like $_. Which you don't use in real programs Oh really? What's wrong with $_ and since when it is?
  - sliverstorm 13y ago
    It's kind of obtuse. If you have to type out "$_", you might as well declare it and give it a good name. I personally have no issues doing: foreach @array { chomp; print; } But as soon as I have to type "$_" I make a real variable.
    - snaky 13y ago
      What's wrong to type $_ if you want to print "`$_'\n" in your example? Etc. I don't see any problem with that as $_ is clearly states that's a loop counter. And let's don't even talk about map/grep/sort and schwartzian transform.
      - pfortuny 13y ago
        I don't think he sees that as a Problem. Only he thinks using it explicitly is not to his taste. I have a similar attitude: make it explicitly a new var if it is going to appear in the code. Your example is perfectly OK. TIMTOWTDI, really.
    - singingfish 13y ago
      $_ is pronounced "it" and should only be used in small blocks of code. This is in much the same way that in a paragraph of text "it" should only be used for transitory sentences on the same topic as the previous one.
  - btilly 13y ago
    The problem is that $_ is global and always in package main. A specific problem that fixed this in my memory was a bug in my co-worker's code which boiled down to his looping over an array with $_, then calling a function in his loop that was in a CPAN library that assigned to $_. The result was that he wiped out his whole array. Whenever you are calling out to code that someone else wrote, you don't know if issues like that could exist, and therefore it isn't safe to use $_. Conversely if you're writing code that someone else will call, be a good citizen and don't assign to $_ either implicitly or explicitly.
- jerf 13y ago
  I like local for two big uses: One, in unit testing, it's a cheap way to completely mock out a function within some scope. I know there's various test methods for that, but frankly local'ing a glob is so easy both to use and to make do exactly what I need that it's often still easier than even invoking the library. Second, I love it for security-related stuff where I really don't want something to escape a scope. I have a value that represents the current user I am processing a request for, which is used for security checks, and by local'ing the variable in the context of the handler, I can be very confident that it absolutely, positively will not escape into the next request. It also turns out to mean that if you're in a code base that has some unfortunate "global" variables, that local lets you turn them into much less "global" variables, as you can local them with confidence about how it won't escape out of scope. Of course, the better solution is to not do that, or to fix it, but we don't live in a perfect world....
chromatic 13y ago
Can you prevent functions you call from accessing variables in your scope? Perl's access control model uses a metaphor of polite permission. Without hardware enforcing memory protection, any memory protection at the language level is a modest barrier for the determined anyhow.

acqq 13y ago

The changes: http://search.cpan.org/~rjbs/perl/pod/perldelta.pod http://search.cpan.org/~rjbs/perl/pod/perldelta.pod

alberth 13y ago

Only 82 more minor releases until Perl 6 will be available.

sigzero 13y ago
Perl 5 will not ever go to Perl 6. Although you probably forgot the sarcasm tag. :)
latk 13y ago
Almost ;-) The current perl version is 5.018000, so that would take 982 releases until the numbering scheme breaks down. Of course, Perl v-strings can have elements of INT_MAX each, but I doubt such high numbers would ever be used, for back-compat reasons.

Su-Shee 13y ago

Perl 6 releases itself monthly for YEARS now. http://rakudo.org/how-to-get-rakudo/ http://rakudo.org/how-to-get-rakudo/ http://rakudo.org/downloads/rakudo/ http://rakudo.org/downloads/rakudo/

chromatic 13y ago
To be fair, so does Perl 5. Perl 5.18.0 happens to be the yearly major release. To my knowledge, Rakudo hasn't reached the point where its developers call any Star (runtime plus libraries) release a "major release" of the sort that users ought to use in the wild for a year or more.
rmah 13y ago
Perl 6 isn't perl.
- mhd 13y ago
  I think there should be some kind of changing of names. For a while it looked like it's another incremental step, if a big one. Which obviously requires running two implementations in parallel for a while -- similar to Python 2 and 3, or several operating systems and distros. But right now, especially once Perl development really picked up, it might be time to "divorce" the two languages. It seems more like Algol60 vs. Algol68, or Modula-2 vs. Modula-3. Sure, there's a number in there, but it isn't just about the version of the main implementation. Having said that, kudos to the Perl team. I really like that they now release new versions pretty regularly, which is a good sign to show people that Perl5 ist still very much alive and nobody needs to hold their breath for the time being. If only I could use something more recent than 5.8 at work...
  - espadrine 13y ago
    Perl5 users won't switch to Perl6 because they're working on Perl5 code and don't want to change their habits. Non-Perl devs won't switch to Perl6 because the P word scares them. So, yes, changing the name might be a good idea. And making an enjoyable web-based tutorial.

creaktive 13y ago

perlbrew install -j 8 -v http://cpan.metacpan.org/authors/id/R/RJ/RJBS/perl-5.18.0.tar.bz2 http://cpan.metacpan.org/authors/id/R/RJ/RJBS/perl-5.18.0.ta...

prollyignored 13y ago

I was a Perl lover once. And now it seems I understand the haters. Just don't use Perl. The language seems fine, productive, even sublime at first but you will encounter some horrible design features. Just read the following, http://markmail.org/message/h2spyi5za4qheuft http://markmail.org/message/h2spyi5za4qheuft -- Perl's data structure serialization is leaky. Thought you made an int ? Whoa ... serialized as a string. http://blogs.perl.org/users/rurban/2013/02/no-indirect-considered-harmful.html#comment-370624 http://blogs.perl.org/users/rurban/2013/02/no-indirect-consi... -- A language feature causing a burnout ? Well fuck me ! That's just a tip of the iceberg. PHP, a fractal of bad design ? Perl, a quantum bomb, waiting to tick off. The Modern Perl movement is like saying "I'll close my eyes and crime ceases to exist." No best practices will save you from broken language features. The people who maintain Perl source code, are not a _fan_ of Modern Perl. They won't make "strict" the default or introduce signatures or better OOmodel. The people who proclaim "Modern Perl" won't fork. Even this release shows how clueless Perl maintainers are ! * They released a switch statement long long back * And now they mark it even as "experimental" because of the leaky "my $_" scope. Oh God ! I will never emotionally invest in another tool. EDIT: Neutral language.

hahainternet 13y ago
I downvoted you because of a) The poor formatting of your post as a stream of conciousness b) The condemnation of a language based on a single relatively minor bug c) The unsupported assertions and unrelated criticisms like not enabling strict by default
- prollyignored 13y ago
  I use points as I am a bad writer. * Don't use $a, $b for variable names, affecting sort * Don't use each for iterating over hashes * Global effects of .. * next operator is dynamic sub foo() { next; #breaks while loop } while(defined (my $e = shift @items)) { # "0", 0 is false foo(); } * http://www.perl.com/doc/FMTEYEWTK/versus/perl.html http://www.perl.com/doc/FMTEYEWTK/versus/perl.html * Exception model based on $_ and $@ * print "$foo's fun!"; * `use constant` is broken * my $a, $b ... declares a global $b. Not DWIM at all. These language features are not worth the debugging time. Regarding c) I am not a fan of use strict. If the community's priority is introducing more features like "my $_" than sane exception handling, I don't want to be a part of it and I won't recommend that language to my boss or the next FOSS project. Did I mention XS bugs ?

jerf 13y ago

Can someone explain the point of the lexical subroutines? [1] In particular, I'm lost on the difference between sub outer { my $closurevar; my $inner = sub { ... use $closurevar... }; } and sub outer { my $closurevar; my sub inner { ... use $closurevar... } } (I mean this as an honest question. That said, I do hope that I'm missing something and this is more than just a syntax gloss.) [1]: http://search.cpan.org/~rjbs/perl-5.18.0/pod/perlsub.pod#Lexical_Subroutines http://search.cpan.org/~rjbs/perl-5.18.0/pod/perlsub.pod#Lex...

latk 13y ago
In the end, everything is syntax. In the first solution, the inner sub would be called as "$inner->()" or "&$inner()". With lexical subs, we get the much nicer syntax "inner()". This decreases the syntactic pain when structuring your code to use nested functions, thus encouraging good design. Oh, and I guess lexical subs can have prototypes, which were ignored when calling a coderef with `&` or `->()`. This allows to create really nice, but properly scoped pseudosyntax.
- prollyignored 13y ago
  > This decreases the syntactic pain use 5.018; no warnings "experimental::lexical_subs"; use feature "lexical_subs"; Don't use perl experimental features. Not portable. Not well thought. May break horribly. "state sub creates a subroutine visible within the lexical scope in which it is declared. The subroutine is shared between calls to the outer sub." So you should be using "state sub" Or use python which has non-experimental "inner functions"
  - latk 13y ago
    You make some very good points esp. wrt verbosity. However, I don't care about portability or not using experimental features for personal or exploratory projects: stability is silver, conciseness is gold. The "state" subs are a consequent extension of the variable declaration keywords "my", "state", and "our". I can see myself using "my subs" in the future, the other possibilities have less practical use. "my subs" are proper closures, so they are not shared. But, somebody will probably write a "lexsub" pragma that does away with the "no warnings ...", and portability becomes less of an issue over the course of time, much like I can nowadays treat the features of v5.10 as given. Perl had nested functions since v5, just with akward syntax. Does Python have proper <del>variable declarations</del> closures? That is more of a dealbraker than non-experimental nested function syntax for me ;-)

will1000 13y ago

Is python 3 the new perl 6?

greyman 13y ago

Just curious: Is Larry Wall still involved in Perl development? Haven't heard from him for a long time...

wazoox 13y ago
He's not involved in Perl 5 development anymore AFAIK.
sigzero 13y ago
He is solely working on Perl 6 now.
- colomon 13y ago
  And is fairly active there: https://github.com/TimToady https://github.com/TimToady

mpyne 13y ago

I understand why smartmatch is labeled experimental, but what's the "modern Perl" replacement for given/when? I only use it as a stupid switch statement but I don't want it breaking with Perl 5.22 either...

jevinskie 13y ago
I feel like I was given the impression that they wanted to get smart match "right" and not abandon it. I guess my use of smart match was a mistake. =(

deleted 13y ago

[deleted]