
Perl 5.20.0 released - kamaal
https://metacpan.org/release/RJBS/perl-5.20.0
======
Mithaldu
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/perlsu...](https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsub.pod#Signatures)

    
    
        Postfix dereferencing
    
        $array_ref->@*;
    

instead of

    
    
        @{$array_ref};
    

[https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlde...](https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perldelta.pod#Experimental-
Postfix-Dereferencing)

~~~
LoonyPandora
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/perlde...](https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perldelta.pod#Module-
removals)

~~~
sigzero
I think moving CGI.pm out is major but good!

~~~
ape4
Sorry if this is a dumb question. How do you do CGI now?

~~~
Mithaldu
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.

------
eCa

        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
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
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).

~~~
raiph
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-...](http://usev5.wordpress.com/2014/05/26/here-implement-labels-redo-
here/)

> 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)

~~~
joel_perl_prog
Thank you. That's a really informative and inspiring reply.

~~~
raiph
I hope I'm being helpful. There's definitely a glass half full / half empty
dilemma with talking about P6.

Let me now include a standard caveat list I created last year in an attempt to
ensure balance in the force:

"Perl 6 is not remotely as usable and useful as Perl 5; it has dozens of
users, not millions; it is 100-1000x slower than Perl 5 for a lot of stuff;
the P6 documentation is immature and incomplete; the spec has not reached
6.0.0; the Rakudo compiler has not fully implemented what's already in the
spec; most of the concurrency and parallel implementation has only just begun;
P6 can not currently use CPAN modules; Perl 6 has syntax and semantics that
are not backwards compatible with Perl 5; Perl 6 culture is -Ofun which some
think is incompatible with getting things done; some folk think that Perl 6
code looks like line noise... In summary, there are infinitely many things
wrong with P6."

I hope that hasn't brought you down to earth with too big a bump.

------
__david__
Here's the Changelog:
[https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlde...](https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perldelta.pod)

------
nandhp

        > 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
> 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.

------
octo_t
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.

~~~
peteretep

        > these are going to be littered throughout most perl code 
        > - its definitely in a lot of my code
    

Interesting; I've been programming Perl for almost 20 years, and they're not
in any of mine!

~~~
VLM
I read a lot of files of very raw textual data and if the parsed data tastes
good, it gets stored in a DB for analysis, if not, kicked out as error.

Its going to be fun watching people who do used the POSIX functions try
alternatives. /[A-Za-z]/, I'd like you to meet umlat-u. The POSIX depended on
the locale of the installed software which, assuming that's a feature and not
a bug (usually its a bug) it'll be interesting to watch people reimplement
that "functionality".

This is a fun 13 year old place to start WRT "simple" data verification, not
because it exhaustively covers everything, but its watching a noob start from
the beginning and hit about ten different roadblocks. There are plenty more of
course.

[http://www.perlmonks.org/?node_id=66320](http://www.perlmonks.org/?node_id=66320)

~~~
clscott
There's a regex character class for that

Alphabetical only? $value =~ /[[:alpha:]]/

Ascii only? $value =~ /[[:ascii:]]/

[http://perldoc.perl.org/perlrecharclass.html#Bracketed-
Chara...](http://perldoc.perl.org/perlrecharclass.html#Bracketed-Character-
Classes)

------
edibleEnergy
[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)

------
DHowett

        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
writing scripts that control programs (such as SSH, emacs, nano, etc) that
expect a keyboard and TTY to be controlling them?

~~~
VLM
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.

