3 ms·

The real question is why is there one python. Perl was already doing everything python can do and it is pointless to write every supporting library in 20 differ

by wmnwmn 13y ago

The real question is why is there one python. Perl was already doing everything python can do and it is pointless to write every supporting library in 20 different languages. You can write good or bad code in any language; the language is nearly irrelevant. Of course, I wouldn't propose going to Bourne shell or something.

run4_too 13y ago
The "explosion in an ascii factory" wasn't doing one thing very well at all - make it easy to code. That answers your question, really.
prodigal_erik 13y ago
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.
- chromatic 13y ago
  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.
- justinator 13y ago
  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.
  - draegtun 13y ago
    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 https://metacpan.org/pod/autovivification
  - bonemachine 13y ago
    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.
- draegtun 13y ago
  >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 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.

by wmnwmn 13y ago

run4_too 13y ago

The "explosion in an ascii factory" wasn't doing one thing very well at all - make it easy to code. That answers your question, really.

prodigal_erik 13y ago

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.

chromatic 13y ago
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.
justinator 13y ago
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.
- draegtun 13y ago
  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 https://metacpan.org/pod/autovivification
- bonemachine 13y ago
  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.
draegtun 13y ago
>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 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.