11 ms·

Perl 5.20.0 released

115 points by kamaal 12y ago

__david__ 12y ago
Here's the Changelog: https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perldelta.pod https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlde...
DHowett 12y ago
This deprecation affects things like $\cT, where \cT is a literal control (such as a NAK or NEGATIVE ACKNOWLEDGE character) in the source code. Surprisingly, it appears that originally this was intended as the canonical way of accessing variables like $^T, with the caret form only being added as an alternative. I love perl and use it nigh-unto daily, but—what could possibly have been the thought process behind that? A literal control character?
- deckiedan 12y ago
  writing scripts that control programs (such as SSH, emacs, nano, etc) that expect a keyboard and TTY to be controlling them?
  - VLM 12y ago
    That's actually a stereotypical bug, doesn't work that way. http://perldoc.perl.org/perlvar.html http://perldoc.perl.org/perlvar.html If you try to use and output ^O while thinking you're outputting a literal control-O then you'll be in for a big surprise. The language allows (length) 250 or so character variable names with few restrictions, so using single character names is probably a bug or at least bad style, so when the devs are looking for a class of global "internal-ish" variable names, how about those icky single character names that no one should be using? So that's how you end up with $^V being aliased to a string representation of the version of perl interpreter currently executing. You really shouldn't be using single character variable names so they've been repurposed and attempting to re-re-purpose them might be very exciting.
- bkeroack 12y ago
  As someone with zero Perl experience...is this a joke? People naming variables with literal control characters?!
  - VLM 12y ago
    Yes. Its a running joke WRT general global variables, and they all have a single character synonym. And once you use up the preferred letters, well, stranger things are used. a C programmer who understands command line argument lists would not even remotely be surprised at the contents of the general variable $0. Its probably more "civilized" to call it $PROGRAM_NAME in your code, but whatever. I don't think this is controversial to alias $PROGRAM_NAME to $0 for anyone civilized aka some minimal C experience. Perl tends to be consistent. In a similar style, if you insist on implementing a global general variable like $PERL_VERSION which contains a string of pretty much what it sounds like it contains, to keep things consistent all general vars also have a single character synonym, so welcome to $"control-V" In the "real world" you can write something stupid enough to get yourself fired. This kind of activity probably qualifies unless you have an excellent excuse. Perhaps if you have a complicated if-then statement with numerous clauses and using one individual weird, yet short, variable name allows a debugging programmer to keep the whole control flow in their head instead of scrolling the mess off the screen, then, maybe, its a win. But I wouldn't make a habit of it. Given that you can pretty much transparently "upgrade" or "downgrade" the code with a simple search and replace its not a major crisis. A lot of people use Perl::Critic as a Perl "lint" and a lot of those users put large amounts of the perlvars file in the Variables::ProhibitEvilVariables test although the Perl::Critic authors don't by default include them, which many people consider a bug in Perl::Critic but whatever.
    - gpvos 12y ago
      > Perl tends to be consistent. Well, for a certain kind of consistency, yes. From the perlfunc manpage, about the return values of Perl's operators and functions in scalar versus list context: In general, they do what you want, unless you want consistency.
    - Mithaldu 12y ago
- emmelaich 12y ago
  Could be worse! "Why does Java allow control characters in its identifiers?" http://stackoverflow.com/questions/4838507/why-does-java-allow-control-characters-in-its-identifiers http://stackoverflow.com/questions/4838507/why-does-java-all...
octo_t 12y ago
The biggest change is the move towards deprecating ascii-related functions: Use of any of these functions in the POSIX module is now deprecated: isalnum, isalpha, iscntrl, isdigit, isgraph, islower, isprint, ispunct, isspace, isupper, and isxdigit these are going to be littered throughout most perl code - its definitely in a lot of my code.
- jbert 12y ago
  subroutine signatures look pretty interesting to me, albeit experimental. https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsub.pod#Signatures https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsu... edit: and the copy-on-write string concatenating has the potential to speed up a lot of code, I think.
  - nnq 12y ago
    'subroutine signatures' is such a basic and expected feature that it isn't even named in other languages. People just assume "it has to be there"... This is what makes people run way from Perl nowadays. I recently tried to convince someone that Perl is superior to PHP. When he saw the sub and $_ and shift he was like "I'm not touching this with a ten foot pole". And there was nothing I could say. Compared to something like PHP 5.4, Perl looks like "mildly evolved stone age shell scripting with some chinese characters in it". And I say this saddened because I still wish PHP wouldn't have won the "battle for the web" over Perl.
    - emmelaich 12y ago
      I have to agree. Perl was an early love of mine. I was excited when subroutine prototypes came to Perl. Sadly they were almost completly unlike prototypes in any other language and no-one used them. Subroutine signatures look like another attempt. Sorry but too late.
      - Mithaldu 12y ago
        You were excited in 1996-Feb-29 when 5.002 was released? Also, prototypes are widely used as syntax hints for the perl compiler and were never meant as signatures.
eCa 12y ago
Perl 5.20.0 represents approximately 12 months of development since Perl 5.18.0 and contains approximately 470,000 lines of changes across 2,900 files from 124 authors. Thank you all.
tenfingers 12y ago
Perl gives me the impression of being one of the few language that's still evolving significantly on a syntax level despite being so old.
- joel_perl_prog 12y ago
  Definitely. And as I have lamented in several places online, as well as verbally in discussions about it, I really love Perl, the language, despite its warts. (For example, I view the slurpy subroutine argument style to be an advantage, if used correctly, rather than a wart; that said, having the option of formal parameters would be nice...) I think we are well past the point now where the language itself is no longer the center of the discussion. Or should not be. What we have is a single back end that's difficult to work on, and which can only target one platform. It's compiled C. Naturally, that's not so bad, as we see Perl is everywhere that Linux is. Which is ... basically everywhere. But how about a Perl 5 interpreter for the JVM? How about a Perl 5 to Javascript compiler (sort of like Clojurescript)? Or just any other target you can imagine. I really feel like the difficulty of working on the Perl 5 internals limits the language--and ultimately, will kill it. "Kill it," of course, is a relative term. Perl 5 will most likely never truly die. Indeed, I'm writing (what I think is pretty cool) Perl 5 code right at this moment, and putting it on Github and CPAN. But in terms of attracting new blood, new developers, young teams of vocal and enthusiastic programmers... I just don't see that happening. To me, it's a great sadness. I have yet to find another language that I love as much as Perl (and I wouldn't mind doing so, at this point).
  - rurban 12y ago
    Regarding the "Perl 5 interpreter for the JVM": See rakudo-jvm. It can run perl5 and perl6 code, and has proper threading support, but the perl5 backend is still in development. Regarding the "Perl 5 to Javascript compiler": See perlito perlcc, the static C compiler is very stable and used in production.
  - raiph 12y ago
    I like Perl 6 (P6). I would like Perl 5 folk pondering P5's internals or its future to properly investigate and understand P6's role. > how about a Perl 5 interpreter for the JVM? In the opening few minutes of Patrick Michaud's 2013 video "Perl on the JVM", he notes that Jesse Vincent suggested "Perl 6 is Perl's best (only?) hope for running on JVM/.NET". https://www.youtube.com/watch?v=XgPh5Li3k4g https://www.youtube.com/watch?v=XgPh5Li3k4g Have you read about FROGGS' v5? http://usev5.wordpress.com/2014/05/26/here-implement-labels-redo-here/ http://usev5.wordpress.com/2014/05/26/here-implement-labels-... > I really feel like the difficulty of working on the Perl 5 internals limits the language--and ultimately, will kill it. There's been a serious effort to clean up the internals in recent years. But yeah, part of the point of P6 was to develop much better internals. Rakudo and the NQP compiler toolchain are not only well designed but also almost entirely written in P6 code. (Counting NQP as P6.) > attracting new blood, new developers, young teams of vocal and enthusiastic programmers... I just don't see that happening. Even in the face of its disastrous reputation, P6 still manages to attract new blood. Aiui the guy who writes the P6 weekly news (http://p6weekly.wordpress.com/ http://p6weekly.wordpress.com/) contributed to the Python core before getting in to P6. This year I've seen smart kids visit #perl6 for the first time, chat knowledgeably about a lisp or ML, and start to contribute. Some well known P5 folk such as Nicholas Clark (one of the few folk ever paid by TPF to hack on the P5 internals) and lizmat have fully turned their focus toward P6 in the last year or so. > I have yet to find another language that I love as much as Perl (and I wouldn't mind doing so, at this point). What about hanging out on #perl6 for a while (prime time is about 8am thru 8pm EST, 7 days a week) to chat with folk and see what there is to see? https://kiwiirc.com/client/irc.freenode.net/perl6 https://kiwiirc.com/client/irc.freenode.net/perl6
Mithaldu 12y ago
For those who do not wish to read the entire changelog, the two important changes are these: Subroutine Signatures sub foo ($left, $right) { return $left + $right; } https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsub.pod#Signatures https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsu... Postfix dereferencing $array_ref->@*; instead of @{$array_ref}; https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perldelta.pod#Experimental-Postfix-Dereferencing https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlde...
- LoonyPandora 12y ago
  Important to note that postfix dereferencing is experimental, and does not replace the existing method of dereferencing. Also, I think the deprecation of core CGI.pm is pretty major. For now it just issues a deprecation warning, but will be removed totally from core in future versions, only being available via the CPAN. https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perldelta.pod#Module-removals https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlde...
  - sigzero 12y ago
    I think moving CGI.pm out is major but good!
    - ape4 12y ago
      Sorry if this is a dumb question. How do you do CGI now?
      - Mithaldu 12y ago
        You install one of the many modules from CPAN, i.e. Plack, Dancer, Mojolicious, CGI. The only change is that an old module that has way too much badly implemented functionality has been set on the path towards removal from the default Perl installation.
      - jevinskie 12y ago
nandhp 12y ago
> The "interpreter-based threads" provided by Perl are not the > fast, lightweight system for multitasking that one might expect > or hope for. Threads are implemented in a way that make them > easy to misuse. Few people know how to use them correctly or > will be able to provide help. That's too bad; I know that threads were very unstable and buggy, but I wish they had been improved them instead of considering them "to have been mistakes". Also on the unfortunate side, CGI.pm has been deprecated and will need to be installed from CPAN. On a happier note, IO::Socket::IP has been added; which finally gives Perl built-in IPV4/IPv6 parity (i.e. one module that can do the jobs of both IO::Socket::INET and IO::Socket::INET6).
- Mithaldu 12y ago
  > That's too bad; I know that threads were very unstable and buggy, but I wish they had been improved them instead of considering them "to have been mistakes". No snark: Patches welcome. There have been people who tried to implement better threads for Perl ( https://metacpan.org/release/threads-tbb https://metacpan.org/release/threads-tbb , https://metacpan.org/release/threads-lite https://metacpan.org/release/threads-lite ). However the task is such a monumentally difficult one, that unless you have considerable ressources available (Java, Go), you're unlikely to get a very good implementation of them (Python, Perl). Perl being entirely volunteer-developed means that there currently simply is nobody with both the knowledge, and the available time, to do this. If you think you can do it, or know someone who can, please by all means give it a try.
edibleEnergy 12y ago
https://metacpan.org/pod/perldata#Key-Value-Hash-Slices https://metacpan.org/pod/perldata#Key-Value-Hash-Slices Hash slices look slick: %h = (blonk => 2, foo => 3, squink => 5, bar => 8); %subset = %h{qw[ foo bar ]}; # key/value hash slice # %subset is now (foo => 3, bar => 8)

115 points by kamaal 12y ago

Here's the Changelog: https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perldelta.pod https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlde...

DHowett 12y ago

This deprecation affects things like $\cT, where \cT is a literal control (such as a NAK or NEGATIVE ACKNOWLEDGE character) in the source code. Surprisingly, it appears that originally this was intended as the canonical way of accessing variables like $^T, with the caret form only being added as an alternative. I love perl and use it nigh-unto daily, but—what could possibly have been the thought process behind that? A literal control character?

deckiedan 12y ago
writing scripts that control programs (such as SSH, emacs, nano, etc) that expect a keyboard and TTY to be controlling them?
- VLM 12y ago
  That's actually a stereotypical bug, doesn't work that way. http://perldoc.perl.org/perlvar.html http://perldoc.perl.org/perlvar.html If you try to use and output ^O while thinking you're outputting a literal control-O then you'll be in for a big surprise. The language allows (length) 250 or so character variable names with few restrictions, so using single character names is probably a bug or at least bad style, so when the devs are looking for a class of global "internal-ish" variable names, how about those icky single character names that no one should be using? So that's how you end up with $^V being aliased to a string representation of the version of perl interpreter currently executing. You really shouldn't be using single character variable names so they've been repurposed and attempting to re-re-purpose them might be very exciting.
bkeroack 12y ago
As someone with zero Perl experience...is this a joke? People naming variables with literal control characters?!
- VLM 12y ago
  Yes. Its a running joke WRT general global variables, and they all have a single character synonym. And once you use up the preferred letters, well, stranger things are used. a C programmer who understands command line argument lists would not even remotely be surprised at the contents of the general variable $0. Its probably more "civilized" to call it $PROGRAM_NAME in your code, but whatever. I don't think this is controversial to alias $PROGRAM_NAME to $0 for anyone civilized aka some minimal C experience. Perl tends to be consistent. In a similar style, if you insist on implementing a global general variable like $PERL_VERSION which contains a string of pretty much what it sounds like it contains, to keep things consistent all general vars also have a single character synonym, so welcome to $"control-V" In the "real world" you can write something stupid enough to get yourself fired. This kind of activity probably qualifies unless you have an excellent excuse. Perhaps if you have a complicated if-then statement with numerous clauses and using one individual weird, yet short, variable name allows a debugging programmer to keep the whole control flow in their head instead of scrolling the mess off the screen, then, maybe, its a win. But I wouldn't make a habit of it. Given that you can pretty much transparently "upgrade" or "downgrade" the code with a simple search and replace its not a major crisis. A lot of people use Perl::Critic as a Perl "lint" and a lot of those users put large amounts of the perlvars file in the Variables::ProhibitEvilVariables test although the Perl::Critic authors don't by default include them, which many people consider a bug in Perl::Critic but whatever.
  - gpvos 12y ago
    > Perl tends to be consistent. Well, for a certain kind of consistency, yes. From the perlfunc manpage, about the return values of Perl's operators and functions in scalar versus list context: In general, they do what you want, unless you want consistency.
  - Mithaldu 12y ago
emmelaich 12y ago
Could be worse! "Why does Java allow control characters in its identifiers?" http://stackoverflow.com/questions/4838507/why-does-java-allow-control-characters-in-its-identifiers http://stackoverflow.com/questions/4838507/why-does-java-all...

octo_t 12y ago

The biggest change is the move towards deprecating ascii-related functions: Use of any of these functions in the POSIX module is now deprecated: isalnum, isalpha, iscntrl, isdigit, isgraph, islower, isprint, ispunct, isspace, isupper, and isxdigit these are going to be littered throughout most perl code - its definitely in a lot of my code.

jbert 12y ago
subroutine signatures look pretty interesting to me, albeit experimental. https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsub.pod#Signatures https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsu... edit: and the copy-on-write string concatenating has the potential to speed up a lot of code, I think.
- nnq 12y ago
  'subroutine signatures' is such a basic and expected feature that it isn't even named in other languages. People just assume "it has to be there"... This is what makes people run way from Perl nowadays. I recently tried to convince someone that Perl is superior to PHP. When he saw the sub and $_ and shift he was like "I'm not touching this with a ten foot pole". And there was nothing I could say. Compared to something like PHP 5.4, Perl looks like "mildly evolved stone age shell scripting with some chinese characters in it". And I say this saddened because I still wish PHP wouldn't have won the "battle for the web" over Perl.
  - emmelaich 12y ago
    I have to agree. Perl was an early love of mine. I was excited when subroutine prototypes came to Perl. Sadly they were almost completly unlike prototypes in any other language and no-one used them. Subroutine signatures look like another attempt. Sorry but too late.
    - Mithaldu 12y ago
      You were excited in 1996-Feb-29 when 5.002 was released? Also, prototypes are widely used as syntax hints for the perl compiler and were never meant as signatures.

eCa 12y ago

Perl 5.20.0 represents approximately 12 months of development since Perl 5.18.0 and contains approximately 470,000 lines of changes across 2,900 files from 124 authors. Thank you all.

tenfingers 12y ago

Perl gives me the impression of being one of the few language that's still evolving significantly on a syntax level despite being so old.

joel_perl_prog 12y ago
Definitely. And as I have lamented in several places online, as well as verbally in discussions about it, I really love Perl, the language, despite its warts. (For example, I view the slurpy subroutine argument style to be an advantage, if used correctly, rather than a wart; that said, having the option of formal parameters would be nice...) I think we are well past the point now where the language itself is no longer the center of the discussion. Or should not be. What we have is a single back end that's difficult to work on, and which can only target one platform. It's compiled C. Naturally, that's not so bad, as we see Perl is everywhere that Linux is. Which is ... basically everywhere. But how about a Perl 5 interpreter for the JVM? How about a Perl 5 to Javascript compiler (sort of like Clojurescript)? Or just any other target you can imagine. I really feel like the difficulty of working on the Perl 5 internals limits the language--and ultimately, will kill it. "Kill it," of course, is a relative term. Perl 5 will most likely never truly die. Indeed, I'm writing (what I think is pretty cool) Perl 5 code right at this moment, and putting it on Github and CPAN. But in terms of attracting new blood, new developers, young teams of vocal and enthusiastic programmers... I just don't see that happening. To me, it's a great sadness. I have yet to find another language that I love as much as Perl (and I wouldn't mind doing so, at this point).
- rurban 12y ago
  Regarding the "Perl 5 interpreter for the JVM": See rakudo-jvm. It can run perl5 and perl6 code, and has proper threading support, but the perl5 backend is still in development. Regarding the "Perl 5 to Javascript compiler": See perlito perlcc, the static C compiler is very stable and used in production.
- raiph 12y ago
  I like Perl 6 (P6). I would like Perl 5 folk pondering P5's internals or its future to properly investigate and understand P6's role. > how about a Perl 5 interpreter for the JVM? In the opening few minutes of Patrick Michaud's 2013 video "Perl on the JVM", he notes that Jesse Vincent suggested "Perl 6 is Perl's best (only?) hope for running on JVM/.NET". https://www.youtube.com/watch?v=XgPh5Li3k4g https://www.youtube.com/watch?v=XgPh5Li3k4g Have you read about FROGGS' v5? http://usev5.wordpress.com/2014/05/26/here-implement-labels-redo-here/ http://usev5.wordpress.com/2014/05/26/here-implement-labels-... > I really feel like the difficulty of working on the Perl 5 internals limits the language--and ultimately, will kill it. There's been a serious effort to clean up the internals in recent years. But yeah, part of the point of P6 was to develop much better internals. Rakudo and the NQP compiler toolchain are not only well designed but also almost entirely written in P6 code. (Counting NQP as P6.) > attracting new blood, new developers, young teams of vocal and enthusiastic programmers... I just don't see that happening. Even in the face of its disastrous reputation, P6 still manages to attract new blood. Aiui the guy who writes the P6 weekly news (http://p6weekly.wordpress.com/ http://p6weekly.wordpress.com/) contributed to the Python core before getting in to P6. This year I've seen smart kids visit #perl6 for the first time, chat knowledgeably about a lisp or ML, and start to contribute. Some well known P5 folk such as Nicholas Clark (one of the few folk ever paid by TPF to hack on the P5 internals) and lizmat have fully turned their focus toward P6 in the last year or so. > I have yet to find another language that I love as much as Perl (and I wouldn't mind doing so, at this point). What about hanging out on #perl6 for a while (prime time is about 8am thru 8pm EST, 7 days a week) to chat with folk and see what there is to see? https://kiwiirc.com/client/irc.freenode.net/perl6 https://kiwiirc.com/client/irc.freenode.net/perl6

Mithaldu 12y ago

For those who do not wish to read the entire changelog, the two important changes are these: Subroutine Signatures sub foo ($left, $right) { return $left + $right; } https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsub.pod#Signatures https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsu... Postfix dereferencing $array_ref->@*; instead of @{$array_ref}; https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perldelta.pod#Experimental-Postfix-Dereferencing https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlde...

LoonyPandora 12y ago
Important to note that postfix dereferencing is experimental, and does not replace the existing method of dereferencing. Also, I think the deprecation of core CGI.pm is pretty major. For now it just issues a deprecation warning, but will be removed totally from core in future versions, only being available via the CPAN. https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perldelta.pod#Module-removals https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlde...
- sigzero 12y ago
  I think moving CGI.pm out is major but good!
  - ape4 12y ago
    Sorry if this is a dumb question. How do you do CGI now?
    - Mithaldu 12y ago
      You install one of the many modules from CPAN, i.e. Plack, Dancer, Mojolicious, CGI. The only change is that an old module that has way too much badly implemented functionality has been set on the path towards removal from the default Perl installation.
    - jevinskie 12y ago

nandhp 12y ago

> The "interpreter-based threads" provided by Perl are not the > fast, lightweight system for multitasking that one might expect > or hope for. Threads are implemented in a way that make them > easy to misuse. Few people know how to use them correctly or > will be able to provide help. That's too bad; I know that threads were very unstable and buggy, but I wish they had been improved them instead of considering them "to have been mistakes". Also on the unfortunate side, CGI.pm has been deprecated and will need to be installed from CPAN. On a happier note, IO::Socket::IP has been added; which finally gives Perl built-in IPV4/IPv6 parity (i.e. one module that can do the jobs of both IO::Socket::INET and IO::Socket::INET6).

Mithaldu 12y ago
> That's too bad; I know that threads were very unstable and buggy, but I wish they had been improved them instead of considering them "to have been mistakes". No snark: Patches welcome. There have been people who tried to implement better threads for Perl ( https://metacpan.org/release/threads-tbb https://metacpan.org/release/threads-tbb , https://metacpan.org/release/threads-lite https://metacpan.org/release/threads-lite ). However the task is such a monumentally difficult one, that unless you have considerable ressources available (Java, Go), you're unlikely to get a very good implementation of them (Python, Perl). Perl being entirely volunteer-developed means that there currently simply is nobody with both the knowledge, and the available time, to do this. If you think you can do it, or know someone who can, please by all means give it a try.

edibleEnergy 12y ago

https://metacpan.org/pod/perldata#Key-Value-Hash-Slices https://metacpan.org/pod/perldata#Key-Value-Hash-Slices Hash slices look slick: %h = (blonk => 2, foo => 3, squink => 5, bar => 8); %subset = %h{qw[ foo bar ]}; # key/value hash slice # %subset is now (foo => 3, bar => 8)