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.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.