Hacker News Reader

Comment by prodigal_erik | Hacker News Reader

It's much harder to write correct software in Perl because there are so many bugs it doesn't catch. Almost everything converts a string that isn't numeric to zero instead of dying. ++$a{$x} doesn't even check that %a is initialized, much less actually has $x as a key. By default syscalls that fail set $? (which can be ignored and usually is) and don't die, and making them die breaks a lot of library code that only "works" because it ignores errors. And the production version still makes ridiculous legacy distinctions like

  @a = (1, 2, 3); print "@a\n";
  $a = [1, 2, 3]; print "@$a\n";

which have no expressive value (if lists and hashes had been first-class values there'd be no reason for references to exist as a type) but only cause subtle mistakes.

View on HN

Here's the script:

    #!/usr/bin/perl 
    use strict; 

    ++$a{$x};

and when run, produces,

    Global symbol "%a" requires explicit package name at ./test3.pl line 4.
    Global symbol "$x" requires explicit package name at ./test3.pl line 4.

So, I'm not sure if I see that point. Are you not a fan of autovivification? Because it: rules. I think the only thing one has to understand is the use of exists(), to see if there is, say, a key in a hash, rather than defined():

    #!/usr/bin/perl 
    use strict; 

    my %foo = (batz => undef); 

    for (qw(bar batz)){ 
        if(exists($foo{$_})){ 
            print "$_ exists!\n"; 
            if(defined($foo{$_})){ 
                print "and $_ is defined.\n"; 
            }
            else { 
                print "and $_ is undefined.\n"; 
            }
        }
        else { 
            print "$_ doesn't actually exist\n"; 
    
        }
    }

prints,

    bar doesn't actually exist
    batz exists!
    and batz is undefined.

I think if prodigal_erik is worried about autovivification then perhaps locking the keys might be a good idea?...

  use 5.016;
  use warnings;
  use Hash::Util 'lock_keys';
  
  my %a = (B => 100);  # B but no A defined
  lock_keys %a;

  my $x = 'A';
  ++$a{$x};

Above now throws an error on the last line - Attempt to access disallowed key 'A' in a restricted hash...

Alternatively autovivification can be switched off - https://metacpan.org/pod/autovivification

As it happens, hashes in Perl 5 autovivify by default (rather like defaultdicts in Python). In retrospect, this can seem rather surprising (if not off-putting) to newcomers, so an argument can be made that a more conservative default behavior should have been chosen (like the more "hard-nosed" behavior of standard dicts in Python).

OTOH Perl people tend to like the way we can, for example, create histograms (and nested structures like graphs) a bit more fluently with autovivifying hashes, e.g.:

    my %a;
    for my $x (@x)  { $a{$x}++ }

than if we always had to be saying

    if (exists $a{$x})  {
        $a{$x}++
    }
    else  {
        $a{$x} = 0
    }

Or as Perlistas would be more prone to write (if forced to use a non-vivifying hash):

    exists $a{$x} ? $a{$x}++ : { $a{$x} = 0 }

Or gosh, who knows:

    $a{$x} = exists $a{$x} ? $a{$x}+1 : 0

Or to have sat around and waited for 10 years or so until Hash::Util was invented (after Perl 4's initial release), provided then you knew to look for it, and how), at which point you'd finally be able to say:

    use Hash::Util 'unlock_keys';

But as it happens, when Perl 4 first came out, autovivification (and its cohort, promiscuous ducktyping) were chosen as the default behavior for many of the language's core constructs (not just hashes and arrays). It's just the way Perl rolls. Whether it's the "right" tradeoff to make or not, from a socio-engineering perspective, is an interesting question (and partially a matter of taste). But in general Perl has been pretty consistent in its approach to tradeoffs like these.

>By default syscalls that fail set $? (which can be ignored and usually is) and don't die, and making them die breaks a lot of library code that only "works" because it ignores errors

The solution to this is to use the autodie pragma (https://metacpan.org/pod/autodie) which has been part of the Perl core since 5.10.1 (released in Aug 2009):

  use 5.016;
  use warnings;
  use autodie;

  open my $fh, '<', "somefile";   # this file doesn't exist

So above will now produce a runtime error - Can't open 'somefile' for reading: 'No such file or directory' at...

And autodie is lexically scoped so it won't break any library code.

And the production version still makes ridiculous legacy distinctions like...

You're ignoring context, which is a fundamental design decision in Perl. That's like criticizing C for having pointers while ignoring the design decision to expose memory as a flat space.

Reply on news.ycombinator.com