Live data from Hacker News

Perl 5.18.0 is now available

nntp.perl.org

61–69 of 69 posts

Re: Perl 5.18.0 is now available

#61
post #58
post #37

Earlier quoted context omitted.

> variables, like $_. Which you don't use in real programs Oh really? What's wrong with $_ and since when it is?

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

It's also lexicalized in every loop, so writing to it doesn't affect anything else. The only time I can think of you would have to worry about this is if some function modified $_ without any loop, and I would consider that a bug (similar to any function that set a static class variable indiscriminately).

For example, the following code performs as expected, and prints "123"

    use 5.016;
    use warnings;
    my @a = qw(1 2 3);
    for (@a) {
        my @b = qw(4 5 6);
        for (@b) {
            $_ = 1;
        }
        print;
    }
This code works (prints "123") fine as well:

    use 5.016;
    use warnings;
    sub test {
        my @b = qw(4 5 6);
        for (@b) {
            $_ = 1;
        }
    }
    my @a = qw(1 2 3);
    for (@a) {
        test;
        print;
    }
The following causes a problem (prints "111"). Don't do this, it's stupid.

    use 5.016;
    use warnings;
    sub test {
        $_ = 1;
    }
    my @a = qw(1 2 3);
    for (@a) {
        test;
        print;
    }
The moral? Buggy libraries are buggy, don't use them, or submit a fix.

Re: Perl 5.18.0 is now available

#62

Earlier quoted context omitted.

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

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 * Exception model based on $_ and $@ * print "$foo's fun!"; * `use constant` is…

> my $a, $b ... declares a global $b. Not DWIM at all.

> Regarding c) I am not a fan of use strict

Apparently you also aren't a fan of use warnings, otherwise you would have seen that that my $a, $b doesn't do what you think it does.

    # perl -E 'use strict; use warnings; my $a, $b;'
    Parentheses missing around "my" list at -e line 1.
What you want is

    my ($a, $b);

Re: Perl 5.18.0 is now available

#63
post #61
post #58

Earlier quoted context omitted.

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

It's also lexicalized in every loop, so writing to it doesn't affect anything else. The only time I can think of you would have to worry about this is if some function modified $_ without any loop, and I would consider that a bug (similar to any function that set a static class variable indiscriminately). For example, the following code performs as expected, and prints "123" use 5.016; use warnings; my @a = qw(1 2 3)…

It is not lexicalized, it is localized.

And yes, I both fixed my coworker's code to not use $_, and submitted a patch to the CPAN library with the bug. But the experience taught me to be cautious about $_.

Re: Perl 5.18.0 is now available

#64
post #35

Earlier quoted context omitted.

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

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

Perl had nested functions since v5, just with akward syntax. Does Python have proper variable declarations closures? That is more of a dealbraker than non-experimental nested function syntax for me ;-)

Python has had proper closures forever, just with awkward syntax. But there is nothing you can do with closures in Perl that I can't translate directly into Python code that does the exact same thing in the exact same way. (I may need to switch from a scalar to an array with 1 element so that modifications in a child scope are visible in the outer, but conceptually things remain the same.)

I'm not saying that you should use Python - I switch it up but Perl is my goto language - however you shouldn't spread incorrect rumors about Python.

Re: Perl 5.18.0 is now available

#65
post #63
post #61

Earlier quoted context omitted.

It's also lexicalized in every loop, so writing to it doesn't affect anything else. The only time I can think of you would have to worry about this is if some function modified $_ without any loop, and I would consider that a bug (similar to any function that set a static class variable indiscriminately). For example, the following code performs as expected, and prints "123" use 5.016; use warnings; my @a = qw(1 2 3)…

It is not lexicalized, it is localized. And yes, I both fixed my coworker's code to not use $_, and submitted a patch to the CPAN library with the bug. But the experience taught me to be cautious about $_.

Sorry, that's correct. I have lexical on the brain.

I just think saying not to use $_ in real programs is a bit extreme. Truthfully, I don't use it in for loops at all, but my code invariably uses a lot of maps and greps. To throw away the expressiveness of map and grep because there may be a problem in some third party library I use at some point is too high a price for me. Especially because by the nature of how I use map and grep I think I'm less likely to run into problem code in those cases, and if I do I think it will be fairly obvious.

Re: Perl 5.18.0 is now available

#66
post #5
post #4

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

Perl 6 isn't perl.

Is there even a Perl6? Last I was paying attention, Larry Wall released a spec, everyone argued about it, a few people tried to do reference versions, and no one completed anything usable. Meanwhile, those of us who were trying to get work done moved on to Ruby (Perl's rightful heir) and Python (weird, but reasonable, I suppose).

Re: Perl 5.18.0 is now available

#67
post #42

Earlier quoted context omitted.

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.

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.

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.

Re: Perl 5.18.0 is now available

#68
post #28

Earlier quoted context omitted.

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…

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

> Or use python which has non-experimental "inner functions"

Or most languages in the ML family (like OCaml or Haskell), where multi-argument functions are actually implemented as a series of nested one-argument functions.

Post reply on HN