5 ms·

I felt like being really lame and recommending a best practice like: "Use Python", but the devil interfered, and I actually find myself looking at Perl resource

I felt like being really lame and recommending a best practice like: "Use Python", but the devil interfered, and I actually find myself looking at Perl resources.

phaylon 16y ago
If you're interested in what (part of) the community is up to, I'd suggest the IronMan feed (http://ironman.enlightenedperl.org/ http://ironman.enlightenedperl.org/).
- pyre 16y ago
  The fourth link on that page reinforces the 'write-only' image of Perl: http://www.samuelkaufman.com/blog/2011/04/29/lazy-sprintf-in-perl/ http://www.samuelkaufman.com/blog/2011/04/29/lazy-sprintf-in...
  - pnathan 16y ago
    Uh, it's fairly understandable?
    - berntb 16y ago
      I think pyre built his opinion of a programming language on the humorous first comment in the link... :-) (I don't really like overloading, monkey patching etc in any language.)
      - pyre 16y ago
        My opinion of Perl isn't that it's a write-only language. I just said that it reinforces the 'image' of Perl as a write-only language. Same for stuff like this (actual code I've come across): sub f { shift->do_something(shift, shift) } sub x { shift->do_something(shift)->do_something_else(@_) } Or sub foo { grep { $_[0]->bar($_) } $_[0]->baz() } Note that $_[0] is indexing @_ and $_ is a completely different variable.
        berntb 16y ago
        You can find weird stuff in any language, if you choose bad code that break Best Practices. The default for shift is misused in your examples. 3 shifts of the same array in one statement -- in which order will they be done!? I would personally have to test with a one liner. Perl's expressiveness make both bad and good things easy. (Etc, it is the usual argument.)
        pyre 16y ago
        That first example is better written as: sub f { my ($self, $foo, $bar) = @_; return $self->do_something($foo, $bar); } The shifts all occur in order (at least in those examples). Another confusing example: open(FOO, '-|') or exec 'cat', '-n', $file or die "Could not open 'cat -n $file'"; while(<FOO>) { do_something(); } There are similar example in the Perl docs ('perldoc -f open'). "open(FOO, '-|')" forks and the parent opens a pipe to the child. The open() call returns 1 for the parent, and 0 for the child, so the child executes the 'exec' while the parent drops down to the while loop. The child then dies after the exec command.
        berntb 16y ago
        Sigh, that example from Perldocs is (as I dimly remember), a translation of old C idioms. I don't know what you try to prove by bringing up some trivially bad code examples. (I am not certain about the order the shifts would be evaluated, if I wrote code like that. An attitude from my old C days, since you can trust Perl's eval order. But I got what the pos code did.)
        pyre 16y ago
        Sorry, not really trying to prove anything. Though, I have come across code that used those idioms from the Perl docs. The code that it was buried in looked like it was someone that didn't know Perl very well and was probably just copying from the docs. E.g. everything had a function prototype, which is something I've rarely come across even in 'cute' Perl code.

I felt like being really lame and recommending a best practice like: "Use Python", but the devil interfered, and I actually find myself looking at Perl resources.

phaylon 16y ago

If you're interested in what (part of) the community is up to, I'd suggest the IronMan feed (http://ironman.enlightenedperl.org/ http://ironman.enlightenedperl.org/).

pyre 16y ago
The fourth link on that page reinforces the 'write-only' image of Perl: http://www.samuelkaufman.com/blog/2011/04/29/lazy-sprintf-in-perl/ http://www.samuelkaufman.com/blog/2011/04/29/lazy-sprintf-in...
- pnathan 16y ago
  Uh, it's fairly understandable?
  - berntb 16y ago
    I think pyre built his opinion of a programming language on the humorous first comment in the link... :-) (I don't really like overloading, monkey patching etc in any language.)
    - pyre 16y ago
      My opinion of Perl isn't that it's a write-only language. I just said that it reinforces the 'image' of Perl as a write-only language. Same for stuff like this (actual code I've come across): sub f { shift->do_something(shift, shift) } sub x { shift->do_something(shift)->do_something_else(@_) } Or sub foo { grep { $_[0]->bar($_) } $_[0]->baz() } Note that $_[0] is indexing @_ and $_ is a completely different variable.
      - berntb 16y ago
        You can find weird stuff in any language, if you choose bad code that break Best Practices. The default for shift is misused in your examples. 3 shifts of the same array in one statement -- in which order will they be done!? I would personally have to test with a one liner. Perl's expressiveness make both bad and good things easy. (Etc, it is the usual argument.)
        pyre 16y ago
        That first example is better written as: sub f { my ($self, $foo, $bar) = @_; return $self->do_something($foo, $bar); } The shifts all occur in order (at least in those examples). Another confusing example: open(FOO, '-|') or exec 'cat', '-n', $file or die "Could not open 'cat -n $file'"; while(<FOO>) { do_something(); } There are similar example in the Perl docs ('perldoc -f open'). "open(FOO, '-|')" forks and the parent opens a pipe to the child. The open() call returns 1 for the parent, and 0 for the child, so the child executes the 'exec' while the parent drops down to the while loop. The child then dies after the exec command.
        berntb 16y ago
        Sigh, that example from Perldocs is (as I dimly remember), a translation of old C idioms. I don't know what you try to prove by bringing up some trivially bad code examples. (I am not certain about the order the shifts would be evaluated, if I wrote code like that. An attitude from my old C days, since you can trust Perl's eval order. But I got what the pos code did.)
        pyre 16y ago
        Sorry, not really trying to prove anything. Though, I have come across code that used those idioms from the Perl docs. The code that it was buried in looked like it was someone that didn't know Perl very well and was probably just copying from the docs. E.g. everything had a function prototype, which is something I've rarely come across even in 'cute' Perl code.