Your skill will accomplish
what the force of many cannot
Re: "Baby" Perl versus "Bad" Perlby xdg (Monsignor)
|on Dec 04, 2005 at 15:11 UTC||Need Help??|
But what makes "good" baby Perl instead of "bad" baby Perl? Frankly, I'm not sure.
A lot of responses so far focus on the "bad". Maybe this question above is one worth answering?
My wife and I are not (yet) blessed with children, but in the last few years, many of our peers have had their first child and very roughly speaking, this is the kind of progression I've seen in how they talk to their children:
The other interesting thing is when/how corrections happen and it's usually not until the child is really speaking on their own and can comprehend the correction. Up until that point, the approach seems to be to model the desired behavior -- staying about one step ahead of the child in terms of the complexity and correctness.
Ignoring books for the moment, consider the typical response on Perlmonks to a posted question with "baby" Perl. For example, a question about why an array doesn't get what is expected with a simple syntax error in the middle causing the problem:
Not only will the error get pointed out many times over, there will usually be at least one response that more or less says (sometimes directly) "your code sucks" and points out a litany of bad/awkward practices, re-writes the code, points out that they should use a CPAN module instead, or reduces the whole thing down to an elegant one-liner.
I don't think that necessarily helps people learn. Extending from the real "baby-talk" analogy, the degree of correctness and complexity really ought to be tuned to the level of the person posting. Admittedly, this is often hard to tell from a post. But I don't ++ a post if looks like someone is trying to show off by bashing an obvious beginner. (There's a good martial arts analogy there, too.)
To me, good "baby" Perl is just simple Perl. It might do something in a longer way (e.g. loops vs map/grep). It might not always reflect best practices (e.g. checking for error on open). It might not utilize more advanced syntax/features (e.g. slices or regex).
This is different than "foreign" Perl, which uses complicated concepts and approaches for other languages instead of more natural Perl expressions. The classic example is the C-style for counter. The longer version is harder to teach than the shorter version.
One of the reasons that I think that Learning Perl is such a great book is that it actually teaches baby Perl -- or a progression through it. For example, strict doesn't come up until page 63 of 228 (not counting appendices) -- a lot of perfectly good "baby" Perl is shown without being pedantic about strict. As another example, files are opened first without checking for errors, and then error checking is added a couple pages later, but with this cumbersome approch (p.83):
Why not "or die"? Because more advanced control structures don't get introduced for another 52 pages and the idiomatic "open or die" isn't shown for another 17 pages after that. The book speaks in good baby Perl until the reader is ready for more advanced concepts.
Ovid ended with this question:
when does ignorance of a better technique mean their technique is bad?
There is a difference between ignorance and error. Most of the examples about the book aren't examples of ignorance, they are examples of error. Or, perhaps its better said that they are examples of ignorance, but they show ignorance of correct technique, not better technique. Someone writing a book shouldn't be ignorant. Someone learning Perl usually is.
As monks, we should recognize that ignorance of better technique is part of the learning process, and we should tune our responses to questions to help the questioner learn at a level they can absorb, not demonstrate our mastery of better techniques. These are not always the same thing.
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.