http://www.perlmonks.org?node_id=513960


in reply to "Baby" Perl versus "Bad" Perl

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:

# lots of baby perl... @my_list = 1, 2, 3; # lots of baby perl...

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.

for ( my $i = 1; $i <= 10; $i++ ) { ... } for ( 1 .. 10 ) { ... }

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):

if( ! open LOG, ">>logfile) { die "Cannot create logfile: $!"; }

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.

-xdg

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.

Replies are listed 'Best First'.
Re^2: "Baby" Perl versus "Bad" Perl
by McDarren (Abbot) on Dec 04, 2005 at 15:30 UTC
    ++ What a great analogy, and an excellent write-up!!
    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.

    Very well said!

    I can relate to this, because as Perl novice I often find that some responses to questions that I have asked have gone completely over my head. And I'll also admit that I sometimes fall victim to the trap of trying to be too "clever" in response to a posted question. (heh.. although at my level of competence - tying to look clever almost inevitably makes me look downright dumb)

Re^2: "Baby" Perl versus "Bad" Perl
by Aristotle (Chancellor) on Dec 28, 2005 at 13:07 UTC

    FWIW, that progression is considered to be a bad idea. Children learn by imitation. Making noises and speaking in nonsense words to them certainly does not help them, and may actively set them back. You should start out right at stage 3 of your progression: correct use of language with simple grammatical constructs and vocabulary.

    It’s no coincidence that this is also the way to help an immigrant learn the local langauge quickly: no pidgin, just speak a little slower so that they can follow.

    (In fact, experience with parents teaching their babies sign language provides evidence that babies have linguistic skills pretty much from day one, long before they learn to speak. See some first-hand experiences.)

    Makeshifts last the longest.

      ...no pidgin, just speak a little slower so that they can follow.

      Damn straight. Reminds me of a quote-

      ...speaking with that omission of syntax stupid people employ when talking to drunken people or foreigners.