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

The fourth link on that page reinforces the 'write-only' image of Perl: http://www.samuelkaufman.com/blog/2011/04/29/lazy-sprintf-in...

Uh, it's fairly understandable?

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.)

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.

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.)

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.

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.)

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.

Perl Best Practices isn't a new book. Pervasive testing took over the (Perl) world a decade ago. There are lots of people doing serious development with Perl.

But that kind of code won't go away, since Perl is a system administration language. It will be the first language lots of people use for fixing things in their file systems, batch download of web pages, etc. Such code will never be pretty. And there is nothing wrong with that.

And btw, I'd use one of the many CPAN modules for fork/exec, but if I was in a hurry I'd copy the Perldoc example. It is a standard idiom in the Unix world.