5 ms·

Because Python is sometimes too "formal" for dirty glue scripts that consist in invoking other commands and parsing their output. Perl blows pretty much every o

Because Python is sometimes too "formal" for dirty glue scripts that consist in invoking other commands and parsing their output. Perl blows pretty much every other language out of the water when you need to process text fast and without too much cruft.

tzs 6y ago
Perl's being more relaxed about creation and manipulation of data structures helps a lot, too those kinds of scripts. Consider this: my %h = (); # an empty hash $h{'foo'}[3]{'bar'} = 'bletch'; Now my hash contains one entry with key 'foo'. That entry is a reference to an array of 4 elements. The first 3 elements of that array are undef, and the 4th is a reference to another hash. That hash contains one entry with key 'bar' and value 'bletch'. In a lot of other languages you would need to explicitly allocate an array of at least 4 elements for $h{'foo'}, and then explicitly allocate a hash for $h{'foo'}[3]. With Perl they just come into existence when you try to store something in them. Is this always good? No. There are many problems where this automatic reification would just hide bugs. If you are, for example, processing data that is supposed to be clean and well specified then parsing it into explicitly allocated data structures that match what you expect and will throw errors if you try to put something in out of range is great. But when you are dealing with data that is not clean and not well specified, being able to get it all in your data structures easily even when there is something wrong or inconsistent in the data can be great. Get it all in, and then you can run cleanup code on it looking for unexpected things, and fixing them or alerting you that you need to add more cases to the fixing code. There's a similar thing on the reading side of Perl data structures. Try to access a hash via a key that does not exist, or an array by an index past the end? You simply get back undef. Is this always good. Like automatic reification, the answer is no. There are many problems where it would be a grave error if the code tried to access an element of a hash or array that it had not previously but in there. For problems where your logic would include a lot of places where you check if an element exists and if it does you add to a total or if it is a non-empty string you include it in something else, the code can be cleaner in a language with Perl's approach. Adding undef to a number is like adding 0, and undef compares as equal to an empty string.
- deleted 6y ago
  [deleted]
- bmn__ 6y ago
  > Is this [autovivification] always good? No. Good thing then that the programmer has the choice to use it or not. repl>>> no autovivification 'store' repl>>> my %h %h = () repl>>> $h{'foo'}[3]{'bar'} = 'bletch' Runtime error: Can't vivify reference at (eval …) > Is this [returning undef for non-existing keys/indexes] always good. […] the answer is no. Good thing then that the programmer has the choice to use it or not. repl>>> use Hash::Util 'lock_keys' repl>>> my %h %h = () repl>>> lock_keys %h () repl>>> $h{no_such_key} Runtime error: Attempt to access disallowed key 'no_such_key' in a restricted hash at (eval …) repl>>> package Array::Bounded { use Tie::Array; use base 'Tie::StdArray'; sub FETCH { my ($self, $index) = @_; die "Attempt to access out of bounds index $index in a restricted array" if $index >= $self->@*; return $self->[$index]; } } repl>>> tie my @a, 'Array::Bounded' repl>>> @a = ('a'..'f') @a = ('a'..'f') repl>>> $a[5] f repl>>> $a[6] Runtime error: Attempt to access out of bounds index 6 in a restricted array at (eval …)

tzs 6y ago

Perl's being more relaxed about creation and manipulation of data structures helps a lot, too those kinds of scripts. Consider this: my %h = (); # an empty hash $h{'foo'}[3]{'bar'} = 'bletch'; Now my hash contains one entry with key 'foo'. That entry is a reference to an array of 4 elements. The first 3 elements of that array are undef, and the 4th is a reference to another hash. That hash contains one entry with key 'bar' and value 'bletch'. In a lot of other languages you would need to explicitly allocate an array of at least 4 elements for $h{'foo'}, and then explicitly allocate a hash for $h{'foo'}[3]. With Perl they just come into existence when you try to store something in them. Is this always good? No. There are many problems where this automatic reification would just hide bugs. If you are, for example, processing data that is supposed to be clean and well specified then parsing it into explicitly allocated data structures that match what you expect and will throw errors if you try to put something in out of range is great. But when you are dealing with data that is not clean and not well specified, being able to get it all in your data structures easily even when there is something wrong or inconsistent in the data can be great. Get it all in, and then you can run cleanup code on it looking for unexpected things, and fixing them or alerting you that you need to add more cases to the fixing code. There's a similar thing on the reading side of Perl data structures. Try to access a hash via a key that does not exist, or an array by an index past the end? You simply get back undef. Is this always good. Like automatic reification, the answer is no. There are many problems where it would be a grave error if the code tried to access an element of a hash or array that it had not previously but in there. For problems where your logic would include a lot of places where you check if an element exists and if it does you add to a total or if it is a non-empty string you include it in something else, the code can be cleaner in a language with Perl's approach. Adding undef to a number is like adding 0, and undef compares as equal to an empty string.

deleted 6y ago
[deleted]
bmn__ 6y ago
> Is this [autovivification] always good? No. Good thing then that the programmer has the choice to use it or not. repl>>> no autovivification 'store' repl>>> my %h %h = () repl>>> $h{'foo'}[3]{'bar'} = 'bletch' Runtime error: Can't vivify reference at (eval …) > Is this [returning undef for non-existing keys/indexes] always good. […] the answer is no. Good thing then that the programmer has the choice to use it or not. repl>>> use Hash::Util 'lock_keys' repl>>> my %h %h = () repl>>> lock_keys %h () repl>>> $h{no_such_key} Runtime error: Attempt to access disallowed key 'no_such_key' in a restricted hash at (eval …) repl>>> package Array::Bounded { use Tie::Array; use base 'Tie::StdArray'; sub FETCH { my ($self, $index) = @_; die "Attempt to access out of bounds index $index in a restricted array" if $index >= $self->@*; return $self->[$index]; } } repl>>> tie my @a, 'Array::Bounded' repl>>> @a = ('a'..'f') @a = ('a'..'f') repl>>> $a[5] f repl>>> $a[6] Runtime error: Attempt to access out of bounds index 6 in a restricted array at (eval …)