Larry Wall has a quote somewhere that it's okay to speak baby Perl. After all, you don't look down on a baby for occasionally misconjugating an irregular verb. (Of course, I still can't reliably decline Spanish nouns by gender, and I haven't been a baby for a while.)

Baby Perl and bad Perl may have a lot in common, but the differences are very important. The vital distinction is how each gets written.

Baby Perl avoids well-known Perl idioms. It may have the flavor of another language: it's easy to see the influence of C or PHP or Visual Basic in a Perl program. Experienced programmers can look at the code and say "That's clunky, but it can work."

Bad Perl ignores well-known Perl design and coding practices. The code is poorly-factored. Variable names are obtuse. There's no error checking. Random bits of dead code pop up, sometimes commented out and sometimes live. Everywhere you look you see bad code copied and pasted from known sources of bad code. Global variables appear and disappear. (This is how you write unmaintainable code in any language -- that includes Python, Ruby, and Haskell (except for the global variables).)

Baby Perl can be bad Perl, and bad Perl can be baby Perl, but the difference is in design.

A baby Perl program written as a didactic exercise is fine. A baby Perl program written to run once, then never again, is fine. A baby Perl program written and published on the Internet to live forever in search engine results and caches is fine -- if it's clearly labeled as baby Perl. That's one of my gripes in The Opposite of Modern.

Baby Perl that persists longer than five minutes, that appears as an example of how to use Perl to solve a problem, or that grows into vital code more than a hundred lines long will quickly become bad Perl.

Baby Perl doesn't scale with programmer effort. Perl novices have enough trouble understanding context and how hashes work without worrying about the Law of Demeter, the Single Responsibility Principle, pass-by-value versus pass-by-reference, the Liskov Substitution Principle, and time/space tradeoffs. I had to learn whether elsif contains the second e or is two keywords before worrying about (manual) tail call optimization in Perl.

However.

The Perl compiler can provide tremendous amounts of debugging information, if you know the magic incantations to enable it (see Toward a Modern::Perl). Perl::Critic can analyze a Perl program and report unidiomatic, dangerous, or sloppy uses. (There should be a Perl::Critic for baby Perl. "These variable names have trailing numbers. Have you considered using an array? See perldoc foo for advice.") The built-in perldiag documentation explains what went wrong and how to fix it -- if you've enabled warnings .

In other words, Perl is willing to help novices writing baby Perl only after they've learned how to ask for help.

Fixing that -- making Perl 5.12 modern by default, with backwards compatibility available through use of a pragma -- will help Perl help novices to write better code. That's step one.

As step two, this change immediately breaks all existing Bad Perl code in the world which won't even compile under modern Perl. Good. There is a slight danger in that everyone who's written these examples will update them with the magic incantation to disable all of this help, but at least to make that work people will have to upgrade to a modern Perl release, which isn't so awful in itself.

Step three is to replace all of those bad tutorials and bad examples and bad idiom worms just waiting to propogate through copy and paste and blog with good code -- code that actually works under modern Perl.