Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl 5.20.0 released

metacpan.org

Post reply on HN
Print view View original

21–30 of 85 posts

Re: Perl 5.20.0 released

#21

Post by VLM »

deckiedan wrote: post #6
DHowett wrote: post #3

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?…

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

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.

Re: Perl 5.20.0 released

#22

Post by dotandimet »

octo_t wrote: post #4

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.

They have equivalent regular expression character classes, so they can be replaced https://metacpan.org/pod/perlrecharclass#POSIX-Character-Cla...

Re: Perl 5.20.0 released

#23

Post by BugBrother »

nnq wrote: post #12
jbert wrote: post #7

Earlier quoted context omitted.

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.

'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 somethin…

Check CPAN, there are good signature modules. (No links; they have been posted often, I write on an iPad while eating pizza without fork/knife.)

Edit: After pizza, clean hands. :-) Just google "cpan method signatures" or similar. The extensible syntax of Perl is really cool. Here is a Moose specific example with type constraints: http://search.cpan.org/~ether/MooseX-Method-Signatures-0.47/...

Re: Perl 5.20.0 released

#24

Post by Mithaldu »

VLM wrote: post #19
bkeroack wrote: post #13

Earlier quoted context omitted.

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

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…

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

There is `use English;` for that. :)

Re: Perl 5.20.0 released

#25

Post by jbert »

nnq wrote: post #12
jbert wrote: post #7

Earlier quoted context omitted.

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.

'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 somethin…

Well, it's just that perl for:

    sub foo($x, $y, $z) ...
has up to now been written:

    sub foo {
        my ($x, $y, $z) = @_;
        ...
which is annoying boilerplate I agree, but actually pretty regular. [You mean language xxx has two different ways to declare subroutine lexical vars?]

The people who want to hate perl will continue to hate it.

After the list of reasons they dislike it are resolved, they'll come up with new ones and/or point to "it's not popular enough" (while simultaneously embracing a brand new language which is significantly less popular).

Re: Perl 5.20.0 released

#26

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

Re: Perl 5.20.0 released

#27

Post by _quasimodo »

Mithaldu wrote: post #20
emmelaich wrote: post #16

Earlier quoted context omitted.

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.

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.

  You were excited in 1996-Feb-29 when 5.002 was released?
Not everyone on hn is in their early twenties, i suppose.

Re: Perl 5.20.0 released

#28

Post by Mithaldu »

nandhp wrote: post #26

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

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

Re: Perl 5.20.0 released

#29

Post by rurban »

joel_perl_prog wrote: post #10
tenfingers wrote: post #9

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.

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 longe…

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.

Re: Perl 5.20.0 released

#30

Post by sigzero »

LoonyPandora wrote: post #14
Mithaldu wrote: post #11

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

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

I think moving CGI.pm out is major but good!
Post reply on HN