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";
- 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.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|