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.
I realize that certain people will object. "I've used Perl for fifteen years, and code I wrote back in 1994 still works unmodified on bleadperl today." That's great. Good for you, unless you're still writing baby Perl after fifteen years of experience. If you're not -- if you're the television equivalent who can drive a race car at 300 miles per hour, crash into a wall, catch on fire, and walk away uninjured thanks to a breakaway harness -- then you already know enough to keep your existing code running unmodified. (Hint: PERL5LIB.) Don't tell me that the sophomores at the high school down the street can get by without seatbelts, airbags, and passenger-side emergency brakes in the Drivers Training cars, however.
Baby Perl is great, but it's important to find a gentle way to get those idioms in as soon as possible. You're teaching the habits of a lifetime, after all. Of course, that means I'm constantly reworking my tutorials as I think of different and occasionally better ways to describe the same dang concept.
On languages: I've come to the conclusion that it's okay for a language to break backwards compatibility, especially in the open source world. Is your project intimately dependent on some combination of features and bugs in 5.004? I feel bad for you, but I don't want it to get in the way of code I'm writing today. You can still find and download 5.004. You want to take advantage of feature X in Perl 5.10? Sounds like a good time to refactor your codebase. There are folks in every language crowd who fuss and bother any time there's a major feature shift. I was kinda one of them with Python 2.0. Then again, the whole *point* of a language is to evolve and change and break ties with the past when needed. Otherwise why bother moving on from punchcards?
Backwards compatibility is fine for desktop applications which are expected to deal in multiple formats. But Perl is only expected to know Perl. Perl 5.12 should only be expected to know Perl 5.12.