Its so pleasant to find such resources spreading throughout the community. Perl is one language which could've died easily given its undeserved write-only reputation, but its thriving and making some very cool new stuff while steadily negating the argument of being line-noise (Dancer comes to mind as an excellent project to both read and use).
While Modern Perl and Perl Best Practices seem to be now the defacto texts to follow in this field, I highly suggest to also supplement your learning of good Perl by reading Perl Medic by Peter Scott. While its main purpose is how to maintain a legacy codebase, its an absolute gem when it comes to what type of Perl code you should be churning out.
I'd really like to follow up on this recommendation: I used Perl first as a kind of sed and awk on steroids in the dark days on a VAX running BSD 4.3, wrote simple CGI in it in the early 90's then later recoded a fax gateway in Perl 4 on Solaris 2.4. Like many people, Perl for me was a useful tool, but regularly unreadable, and admitting of very few good practices. In the end, I moved across to other domain-specific languages and only dived into Perl infrequently for data analysis tasks during the last 10-15 years. Writing the same old unmaintainable, unreusable, script-like code, and hating it.
Modern Perl is a revelation! While the first hundred pages are a crystal-clear recap of the basic language (and I found at least a couple of things there that I didn't really know about), the chapters on modern object-orientation (using Moose), exception handling, testing, maintainability, and what features in Perl 5 to avoid are all pithy, to the point and well-argued.
If you're a (self-exiled) Perl coder like I was, give this (e)book a read and see if you might jump back in. I have - and would second frameworks like Perl Dancer as fantastic examples of what the Perl community is up to these days.
I was excited by the title and bought the book, but have been quite disappointed. Nothing especially fancy in there; things like function dispatch tables.
Regardless of their slightly dated information, I'd add to your list the standard 'Perl Cookbook' by Christiansen and Torkington. Likewise 'Programming Perl' by Wall, Christiansen and Orwant. While not perfectly up-to-date, the reader should be able to immediately use the code and if necessary refactor later. Come to think of it the editions I have are of a same vintage as 'Medic' so same advice applies...
It's nothing like PHP, but I still find it to be a bit too much. strict and warnings? Yes. "use feature ':5.12'"? Yes. A metaobject system incompatible with Moose? No thanks. Autoboxing all references? No thanks.
I wrote a pragma called "no nonsense" that is a little saner:
You say "no nonsense" at the top of the lexical scope, then you get strict and warnings, the true value required at the end of the module is automatically added, and any non-method subroutines you import are made un-callable as methods. That's it.
(I personally don't use this, because it's a little too cute. I don't mind saying "use Moose; use true; use namespace::autoclean;" at the top of my classes.)
perl5i performs the valuable services of integrating several useful but disparate extensions into a single working whole, which helps to identify missing features and to encourage collaboration. It's also much easier to install and to enable.
I see it as an experiment as to where Perl 5 could be. Even though I might not use it outside of personal projects, it's still useful.
I think it's lost on me because a lot of these simple problems it allows you to solve with simple code are also equally specific problems. (In a "how many times have you written this routine?" sense, my answer is almost always "once" or "never.") I haven't seen a really good example without a better solution so I've got that "use Kitchen::SinkToo;" feeling.
That's not a bad idea for personal projects if it does save you time. Otherwise I'm not so sure. Experimenting is good though.
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.
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.)
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.)
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.
This seems to border on flame bait. You can't call a situation where you abandon a programming language due to lack of knowledge/experience (or just due to preference) a 'best practice' for that same language. Calling converting all your ancient Perl scripts to Python a 'Perl best practice' is inviting a flame war.
Yeah I was a bit of a jerk. Just too many bad memories and I let my emotions get the best of me. Perl 5 just requires a level of patience and dedication that's just beyond me.
It probably would have been a bit more lighthearted if I replaced Python with Perl 6 in my previous post.
While Modern Perl and Perl Best Practices seem to be now the defacto texts to follow in this field, I highly suggest to also supplement your learning of good Perl by reading Perl Medic by Peter Scott. While its main purpose is how to maintain a legacy codebase, its an absolute gem when it comes to what type of Perl code you should be churning out.