He's going to fight to the last against doing something 'childish', even though I assure him that when I'm coding professionally I'm doing little test scripts more than I'm working on the 'real' program.

Right on, jepri! I just had a quick scan on 4 different accounts here at work, that reveals some 400+ little test scripts. On each machine I have a ~/perl directory where I try out snippets to check how things work. For instance, the other day I had hesitations about how splice works, because I use it so rarely. So I whipped up "muncharr" which looks like:

#! /usr/bin/perl -w

use strict;

my @arr = ('a'..'z');
my $nr = shift || 6;

local $, = ' ';
while( scalar @arr ) {
        my @block = splice( @arr, 0, $nr );
        print "@block\n";
}
[download]

With that, I was able to see straight away that my understanding of how splice worked was in line with reality. It took me about 2 minutes for take the time out to perldoc -f splice and test this out. I was then able to fold the principle back into my main code and safe in the knowledge that at least that part of the code was likely to be bug-free :)

And I suppose it is useful to stress that even little snippets are deserving of strict and -w. Also note how I wrote the script to use default value(s) that can be overriden from the command line.

A good way to get to know splice better is to re-implement push, pop, unshift and shift with it.
A good way to get to know substr better is to create push/pop/unshift/shift functions for strings.

Often, a good way to learn is re-inventing the wheel. I'd rather re-invent a wheel than greet the world.

U28geW91IGNhbiBhbGwgcm90MTMgY
W5kIHBhY2soKS4gQnV0IGRvIHlvdS
ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
geW91IHNlZSBpdD8gIC0tIEp1ZXJk

A good way to get to know splice better is to re-implement push, pop, unshift and shift with it.

Uhm, or you could just read the docs :-)

D:\Development>perldoc -f splice
    splice ARRAY,OFFSET,LENGTH,LIST
    .....
            The following equivalences hold (assuming "$[ == 0"):

                push(@a,$x,$y)      splice(@a,@a,0,$x,$y)
                pop(@a)             splice(@a,-1)
                shift(@a)           splice(@a,0,1)
                unshift(@a,$x,$y)   splice(@a,0,0,$x,$y)
                $a[$x] = $y         splice(@a,$x,1,$y)
[download]

A good way to get to know substr better is to create push/pop/unshift/shift functions for strings.

Well.... Once you know how to implement splice using susbtr you dont need to implement push/pop/unshift or shift, but its true it might be a good exercise. Personally would suggest taking that thought a step further and reimplement Tie::CharArray, by the time you are done if you dont understand Tie's, Array implementation, Splice Implementation and Substr implementation then I would say theres something very wrong... (either with the individual or the code ;-) Oh and it probably is a good idea because you can use the CPAN module for a proper code comparison and review afterward.

Thats what I did to learn Tie the first time anyway... :-)

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

That certainly seems to be the standard teaching method in the scheme and lisp worlds. The number of such books I've seen that have you recoding length and the like. And it seems to work.

This is truly sage advice. I often resort to the 'test' script to fully flesh out a language construct that I don't fully understand or fully test an algorithm/idea that I'm working on.

I find these 'test' scripts very useful. I'm glad that I'm not the only one doing this.

metadoktor

"The doktor is in."

This is one of those books you read away from the computer in a casual manner.

jeffa

This is an "affliction" to which I often fall prey. It slowed me down when I was first learning Perl in the pre-4.0.19 days, and still gets in the way when I try to evaluate newer things for the sake of project planning.

I know that one thing that regularly trips me up is when a book or tutorial use nonsensical examples, ones that the mind automatically dismisses. I get so tired of "Hello World", and SOAP or other web service technologies that seem to think the only application of web services ever is going to be fetching stock quotes. I've kept that in mind as I write the book I'm working on, trying to make the examples interesting enough to at least read once or twice. If the examples don't draw the attention in, then the reader may miss an important point or element. This could make things that much harder later on.

There's a thought: a compendium of simple-but-useful exercises for people to use when learning new languages. Something like, "replicate the ls command, with at leaast n of the switches", as a means of drilling on the language's interface to the file-system related syscalls.

--rjray

I have had experience of training, mentoring and managing people in this category. There are several mistakes that are easy to make:

• Doing the chap's grunt work for him. Apart from losing respect, this is damaging as it re-enforces his arrogance. The best way is to say "No: you do it - or find someone else to help".
• Doing the chap's thinking for him. This is worse. This risks making him dependent on you for any cognitive processing required in problem solving.
• Appearing unapproachable. This appears to countermand the other advice here, but if you make it clear that you are willing to listen to _reasonable_ requests, you will gain respect. A successful approach here is "what would YOU do to solve this problem".
• Being too sparing on the praise when due. many people are quick to find fault, but timely praise reaps dividends. This may earn you pints of beer and lifelong friends.

Update: Interesting to see how I have miss-parsed the English phrase "teaching my flatmate Eiffel". Doh! - there was tiredness and lack of coffee creeping in, but I wonder how any future NLP bots would have coped with this one.

Thankfully I did something similar to your advice (this is all in the past). He wanted to get me into the lab for the last nighter effort. I declined and he went by himself, made some friends who were in the same boat, and got most of the program done. So it sounds like he's getting into the culture a bit too.

I suspect I am too sparing with the praise though.

____________________
Jeremy
I didn't believe in evil until I dated it.

I marvel at how the human brain is able to take tasks that seem difficult and require huge amounts of attention at first, and internalize those with practice so that the mechanics of the task become unconscious, freeing us to focus on the more strategic issues. Unfortunately, that may give us the illusion that something is (or should be) "easy" if we're insufficiently introspective to remember what it felt like to be inexperienced in a particular domain.

Driving a car is a skill most of us probably take for granted, and do often enough that it's become almost automatic, but it takes a lot of training and practice to acquire that skill in the first place. Or writing -- think how much time we spent as children learning the basics of how to hold the pencil and draw the simple letter A! (Or whatever the equivalent in one's native language might be.) Learning to ride a bike, to play a musical instrument, to speak and understand a new language, to dance, to solve mathematical problems, to play chess or poker, to build a house, and yes, to program a computer -- none of them just magically come to you, whether you're 10 years old or 50.

I can imagine your frustration at watching your flatmate ignore this reality. I'm not sure how much you can do for him, though, if he's not willing to acknowledge that developing skills takes time and effort. I'm guessing that either he will discover that his approach is not fruitful and realize he needs to focus on the fundamentals, or -- sad but probably more likely -- decide that computer programming is not something he really wants to become proficient at after all.

Update: The observation that your flatmate doesn't want to do something 'childish' got me thinking. Children are interesting, because although they lack a lot of skills and real-world knowledge acquired through experience, they have some traits that are particularly useful in acquiring those skills and real-world knowledge in the first place: They ask "why", they try new things (except vegetables ;-), they don't worry as much about how people will perceive them. Maybe being a little childish is not such a bad thing!

Personally, I think the whole OO ball of wax is a little much for a beginner. I might start a new programmer with somethink easy like Basic or even... Perl. But he probably has no choice because it's for a class.

One thing I've noticed over the years is that while programming is pretty easy, many people just don't like it, or lack the patience for it. I tell them if it's not fun, don't bother. There are already plenty of us who like it. ("The first rule of Perl Club is...")