Perl 5.20.0 released

https://metacpan.org/release/RJBS/perl-5.20.0

by kamaal • 12 years ago

115 76 12 years ago

__david__3• 12 years ago

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

DHowett• 12 years 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• 12 years ago

writing scripts that control programs (such as SSH, emacs, nano, etc) that expect a keyboard and TTY to be controlling them?

VLM3• 12 years ago

That's actually a stereotypical bug, doesn't work that way.

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• 12 years ago

As someone with zero Perl experience...is this a joke? People naming variables with literal control characters?!

VLM3• 12 years 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.

emmelaich3• 12 years ago

Could be worse!

"Why does Java allow control characters in its identifiers?"

http://stackoverflow.com/questions/4838507/why-does-java-all...

octo_t• 12 years 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.

jbert4• 12 years ago

subroutine signatures look pretty interesting to me, albeit experimental.

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• 12 years 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.

peteretep• 12 years ago

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

VLM3• 12 years ago

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

eCa• 12 years 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• 12 years 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_prog2• 12 years 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• 12 years 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.

raiph3• 12 years 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

Have you read about FROGGS' v5?

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

ionforce• 12 years ago

Try Scala. It's a very expressive language that does not sacrifice on power (JVM/type safety).

As a long time professional Perl programmer, I've given up on it. The heartache it has caused on enterprise teams I've been on is not worth the rise in blood pressure. And I'm starting to think that it is inefficient in its yield per unit of effort ratio. Writing good, scalable, clean, modern Perl requires so much couching and qualifying. My teammates couldn't even write good Perl. And so despite my want of evangelizing it, pitching to younger programmers is probably not useful/efficient.

But no, I'm not bitter. =)

Mithaldu9• 12 years 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/perlsu...

    Postfix dereferencing

    $array_ref->@*;

instead of

    @{$array_ref};

https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlde...

LoonyPandora• 12 years 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/perlde...

sigzero• 12 years ago

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

nandhp• 12 years 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).

Mithaldu9• 12 years 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-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• 12 years ago

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)

Perl 5.20.0 released

Related Stories