in reply to Re^7: Best practice or cargo cult?
in thread Best practice or cargo cult?

Of course, that's not to say that there aren't some people who do just blind adopt it because I said so.

The sad fact is that being called Best Practices these hints of yours you have outlined in a book will not blindly be adopted by skillful coders (push ikegami's home node button), but they will be enforced by others that don't have any clue about perl - our PHBs and project managers.

If soemeone like TheDamian, and oodles of other skillful people, call them Best Practices, they must be, and heeded, right?

Unfortuately, there's nothing I can do about that. I spent most of the first chapter of PBP pleading for readers to assess, consider, try, and then critically evaluate my advice, but not everybody has the will, the interest, the time, or (frankly) the capacity to do that.

No, you can't do anything about that, now that the book is out. The opportunity was in considering the title of that book. Had you given it a title like Perl 5 Pitfalls (and how to avoid them) it's success would not have been less, but it wouldn't beget the nefarious consequences it does now. IMHO Best Practices is wrong because there aint "best" - all practices depend on context.

For those that don't, at least they're blindly adopting a convention that works, that is consistent, that is less error-prone than the Perl 5 defaults, that has few drawbacks or downsides, and that many more clueful Perl folks agree is a good idea and have adopted themselves.

If the Perl5 defaults are so error prone, then why on earth didn't you work to change them in the perl core rather than publishing a book about your view of "best defaults" and calling them "best practices"? I mean, each and every Perl 5 default has it's history and reason, and calling them implicitly Bad Practices is no service to Perl.

Many skillful perl coders have become skillful (amongst other things) by falling into traps, gotten hurt and bitten, and by finding out why that happened they found enlightenment. The Monastery guards plenty of those stories. And so,

I fully accept that other clueful Perl folks, such as yourself, don't like the convention, and find it annoyingly constraining or less expressive or fun-diminishing.
those that went the hard and rocky way will have to fight convention, they will have to defend their findings and ways, simply because there's an authoritative "Best Practices" book.
However, I'd point out that in many development environments there are good and valid reasons to restrict the freedom, expressiveness, and playfulness of individual developers, not the least of which is that not all developers in the environment are sufficiently flexible, literate, or self-disciplined to cope with the freedom, expressiveness, and playfulness of their more accomplished colleagues.

Restrictions are each development environment's own business. IMHO, "Best Practices" dosen't improve in any way any developer's self-discipline. Self-discipline (as the word says) cannot be imposed from outside. And bottom line - anybody dealing with Perl 5 has to know TIMTOWTDI and constantly learn and will love Perl's pitfalls and dark corners - or they just chose the wrong language. You can't make perl safe and easy by turning it into a subset of itself. Any development environment that doesn't balance highly and lower skilled people is a pain anyways. Your book does not change that. Though conceived with good intent, it may turn out to be the blueprint for a Perl Procrustes Bed (in fact, it already begat such a thing - see Perl::Critic).


_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}