"Bad" Perl is perl that is flawed in other ways; such as using fundamentally flawed algorithms; advanced coding techniques used for obfuscation purposes in production code; parsers and lexers built into the code to handle a configuration file that holds only constants; and so forth.

In other words, truely bad Perl is perl that would remain bad even if refactored, or translated into a completely different language.

"Baby Perl" is just inexperience with Perl idioms; which isn't always a bad thing. I often try to avoid using complicated features of perl when simple features will do the job; the less I have to *think* about the code to make sure that my clever tricks really work; the easier the code is to maintain. I'd rather have three lines I can read than one I can't; but obviously excessively verbose code imposes it's own inherent complexity, so there's a balance to be struck. I try to code to the level of the person who I anticipate will maintain the code. In some respect, my Perl resembles "Baby Perl" by design. I only use features that a novice might misunderstand when it would make the code awkward not to do so, and whenever I do something "clever", I know I'll pay for it later. Six months from now, I'll probably have to explain what I did to a confused maintainer, and while comments help, I'll still have a mini-training excercise on my hands. I do like teaching, but my company is losing money when I give out free training like that, because my time and my co-worker's time could be spent elsewhere more profitably.

So, to recap: "Baby Perl" arises out of ignorance, and is solveable. "Bad Perl" arises out of incompetance or malice, and is not. Having dealt with too much bad Perl lately (6,000 line loops with eight levels of indentation, formatted inconsistantly with typically only 2 column indentation is... bad practice. Exporting local package variables into every single namespace instead of using a global variable in the first place is ... bad design. Making your fundamental data structures tied hashes with a rat's nest of internal function calls, with wierd side effects is... bad design. Localizing various sections of a data structure to modify the impact of key function calls is bad design. Putting your date/time handling code into a custom Perl-XS module that's (a) buggy, and (b) incompatible with the perl version in production is bad practice, given the tonnes of date handling routines on CPAN.

Failing to "use strict" because you don't know it's there in a ten line perl script is not so bad. Failing to use strict because you're too lazy to use it in a 10,000 line perl project is bad.

Just my $0.02

--
Ytrew Q. Uiop

P.S.: On martial arts: I disagree with your premise that Martial artists would claim that the arts are about learning that you don't need to fight. Martial arts teach awareness of how you need to fight; including what degree of force is required or appropriate to a given situation. If a little child attacks an adult, we don't try to kill it; we just stop the attack, and scold the child.

If an adult attacks a martial arts master with a credible threat, the adult will find that the master will defend him/herself using such violence as is appropriate to the situation. The only difference between "ordinary people" and "enlightened" martial arts masters is that a martial arts master has less risk of being hurt by a given attack due to superior skill; and can risk being more lenient while remaining safe.

If the martial arts master was a true pacificfist, (s)he wouldn't have needed to learn how to kill and maim in the first place, before advocating "peace". Remember that the word "martial" means "warlike", and that "martial arts" were the killing tactics used on the battlefields in Asia. Traditions on how to kill with a sword, spear, staff, or with one's bare hands are very insightful, but they were never peaceful in origin or intent. It's easy to romanticize a violent tradition (like "knights in shining armour"), but a history of violence remains violent.