But what makes "good" baby Perl instead of "bad" baby Perl? Frankly, I'm not sure.

It's a lot of little things. Baby Perl can legitmately get away with a lot of things. For instance...

• Baby Perl may not make much use of references.
• Baby Perl usually doesn't attempt to use the Perl5 object model at all, even when it would be a good way to solve the problem at hand.
• Baby Perl does not make significant use of standard Perl idioms (e.g., the orchish manoeuver, the Schwartzian Transform), even when they are a perfect fit for the problem.
• Baby Perl frequently misses good chances to use some of the nicer conveniences Perl provides, such as implicit $_, well-known (or even core) modules, list handling (especially map and grep), builtins that duplicate OS functionality but in a cross-platform way, and so on.
• Baby Perl may read like a first-grade primer:

  There are many statements.
  They are short.
  They are simple.
  Each one is on its own line.
  

     $foo = $foo + 1;
     print "There are now ";
     print $foo;
     print " foo items, for a total of ";
     $total = $foo + $bar;
     print $total;
     print " items altogether.\n";
  [download]

• Baby Perl may leave out comments it should include, or include comments that are needless, especially ones that duplicate the language documentation, e.g., telling what a builtin does. A more experienced programmer would leave these out and instead put in comments that explain at a higher level what the code is accomplishing or why.

On the other hand, *bad* Perl isn't just simplistic; it's plain wrong. Some examples...

• Bad Perl may try to use Perlish features but gets them wrong, e.g., attempting to use slices and messing it up.
• Bad Perl tries to write at a level significantly beyond the programmer's competence in the language, by assuming things must be the same as in some other language the author had previous experience writing; instead of many short statements, now we may combine them in a way that changes the execution order incorrectly, provides something the wrong context, or some similar mistake.
• Bad Perl doesn't just miss chances to catch mistakes; it actively *avoids* them. For instance, while baby Perl may not always check return values where a more experienced programmer would, bad Perl may actually throw an eval { } around something that may die and then never check the result, relying on it to work lest the following code mess something up.
• Bad Perl may contain comments that are actively misleading.

If I had to summarize the difference, I think it has a lot to do with things that aren't specific to the Perl language. Baby Perl doesn't necessarily do things in the best or most Perlish way, but it does them in a way that works, as far as it goes. Really bad Perl does stuff that wouldn't be okay in any language, or that doesn't even work correctly.