|There's more than one way to do things|
Actually ... chanting:
in this community earns elevation via XP. But you do raise very good points, and seeing that you have been programming longer than myself, i realize that you are speaking straight from the "real world" gut. However, i would change "something all new Perl programmers should learn" to "something all new Perl programmers will eventually have to deal with". (as i didn't with one nameless company - instead i left.)
The difference is that i would rather see advice to use strict and warnings than not. The fact that this doesn't happen as often as it should in the real world (let's face it - software design is hard!) doesn't mean that a new Perl programmer shouldn't excercise good practices now before they become ... tainted. Teach 'em the rules now, let 'em break the rules after the learn them. And Perl is all about breaking rules. ;)
Besides, not all companies suffer from the "don't look back" syndrom that seems to accompany leaving strict and warnings out of production code ... i happened to work for two that used strict and warnings in production, as well as CVS religiously and Use Cases regularly. Maybe this wasn't necessary, but we didn't waste time tracking down and fixing obscure bugs either. ;)UPDATE:
I should mention that the one place i don't use strict and warnings is when i write one-liners. My logic is that one-liners are true throw away scripts, and if you need strict and warnings, then it probably shouldn't be a one-liner.
L-LL-L--L-LL-L--L-LL-L-- -R--R-RR-R--R-RR-R--R-RR B--B--B--B--B--B--B--B-- H---H---H---H---H---H--- (the triplet paradiddle with high-hat)
In reply to (jeffa) 3Re: Things every perl programmer should know?