I write a lot of demonstration pieces, and there's always a need for a balance.
Spike solutions / proof of principle and concept work well in front of a class. But then they are subject to major criticism due to a lack of robustness, and for security reasons, if they are published without comment (or even if published WITH comment, as many people seem to ignore comments!)
Fully "salemanproofed" (if you're in sales support) or "Squaddieproofed" (if you're doing military systems) examples are great - except that they contain so much extra testing and checking that you can't see the wood for the trees when explaining them to a newcomer programmer.
Catch 22? To some extent yes, but at times I try to steer the happy medium and it works. For example, I wrote a Perl example in front of the class yesterday ... checking files, opening, reading, writing them in Perl ... it shows many mechanisms and whilst it's not "A Rembrandt" it's a reasonable job.
And I have added comments and POD (Plain Ole Documentation) so that it's useful for other too. See
here (Separate window will open).
A couple of extra comments - yes, I KNOW that
• I should not hard code the file names and paths
• The error messages should be improved
• There should be a check on command line params / a usage line
• Maybe I should use the 3 parameter form of open
• And that you could come up with other issues too.
But it makes a great example to teach the principles!
(written 2007-10-30 23:07:07)
Associated topics are indexed under
P207 - Perl - File Handling
Some other Articles
The Learning Perl crew, October 2007National Speaker - now to get the talk readyA Golf Club Decision - Perl to JavaWhat software version do we teach?Good, steady, simple example - Perl file handlingBetter technology makes for longer commutes?What we teach - expained for the non-technicalThe little gestures that can really countSparse and Greedy matching - Tcl 8.4Buffering of inputs to expect, and match order