|more useful options|
Teaching Perl Idiomsby FoxtrotUniform (Prior)
|on Sep 26, 2001 at 20:46 UTC||Need Help??|
At work, I'm supposed to be putting together a tutorial/training/certification package for Perl: the idea being that once new hires (or old ones :-) have worked through this package, they should know everything they need to about Perl. (Yeah, kind of a lofty goal, but at least this way people won't keep asking me what the funny -> symbol means. I hope.)
One of the problems I'm facing is that people tend to write Perl like they write their Favourite Programming Language -- usually C or Java or Pascal. That doesn't help much: they're losing out on most of the language's best features (like regexes), and they still won't be able to understand code written by a Perl adept a year ago that they're responsible for maintaining. So this training package has to get people thinking in Perl to some extent.
One idea I had to that end: make them write one-liners. Put them in situations where they can't use their standard C toolkit (arrays and for-loops) to solve the problem. I'd have to expose them thoroughly to the concepts beforehand (this has the happy side-effect of teaching me much more about Perl).
When I think about it a bit more, the point isn't to fit the program into one line (although doing so is definitely cool): the point is to demonstrate some of the more elegant bits of Perl by showing off how much time (and code) they can save, and maybe I can do that by restricting the size of the solution.
Problem is, I don't want to encourage people to write line noise that compiles, or completely neglect readability for the sake of "compactness". I also want to avoid telling people what solution to use: for one thing, it's irritating; for another, it's patronizing; for a third, I want them to do the thinking, not me; and finally, I'm sure that someone else will come up with a better solution than I did, perhaps using a different construct, and I'd rather encourage that.
So, I ask the Perl Monks: What (kinds of) questions should I ask, and how should I ask them, to get Perl newbies to think in Perl (rather than use a C-to-Perl dictionary to do the exercises)?--