I learned Perl in the late '90s, after I took a job as a system administrator. I'd programmed a little bit in my previous job: I'd written a small application for the customer service help desk, and I'd written a proof of concept "Notify me when this website has updated!" system that somehow never had its rewrite from Bourne shell to Java 1.1.
After spending two months fixing everything my predecessor had left unfinished, I had a lot of spare time. Good system administrators do. That's why they're so prickly; they hone their arguing skills by bickering on Usenet all day.
Instead, I taught myself Perl. I read a couple of books. I wrote a few programs. Yet the most important technique I've ever learned was to read and write and modify the code of other people.
Back then, I had to read comp.lang.perl.misc for Perl questions. I'd look at the example code, when provided, then run it on my own machine and see if I could figure out the answer. This is much easier now. Now you can go to PerlMonks (for one example) to find tens of thousands of questions and answers and comments.
Short examples were always the best. I had to learn syntax and idioms. Syntax is easy, if you know how to use perldoc. Idioms are more work, but if you pay attention, you can often get invaluable explanations.
Even still, the best way for me to learn was through experimentation. I wish back then I had what I have now, and that's a test framework for learning:
use Test::More 'no_plan';
sub some_example_function { ... }
is( some_example_function( 'a string' ), 'some result', '...' );
is( some_example_function( 1234567 ), 7654321, '...' );
done_testing();Writing hundreds—perhaps thousands— of tiny programs to test pieces of Perl syntax or idioms or techniques and to find out what breaks, what changes, and how I could modify or chain them taught me more than reading a dozen books ever could. In effect I performed what every halfway-decent programmer already did when building programs: ad hoc testing in small pieces.
Test-driven learning offers the same advantage in learning how to program and how to program in a given language and how to program well in a given language that it does to writing and designing and maintaining an application: a formalized system for immediate, unambiguous feedback. Each passing assertion I never wrote would have forced me to express and to formalize my understanding of how Perl works. Each assertion is "yes" or "no". Assertions tend to be small and self-contained. Well-written assertions can read like English descriptions of the expected behavior.
Novices who will become good programmers do this already. Perhaps novices who adopt a test-driven learning system will become better programmers.
