in reply to Teaching Perl Idioms
You have to do both simply because there is so much Perl out there to learn that you cannot bring people up to speed on it. Besides which, there is no person that you are better off losing than the guy who so enjoys coming up with obscure syntax that he cannot read his own code 6 months later.
An extreme example of what you can do would be Re (tilly) 1: to perl or not to perl. (That was for using Perl in an environment of non-Perl programmers. Living within those rules is doable but painful.) My personal list has a lot more than that on it. For instance I want people to understand OO, anonymous functions, closures, and other high-order concepts. (I also don't expect people to pick this up in a short course.)
As for how to get people thinking Perlishly, I would suggest first making sure that they have access to the Cookbook and spend time looking things up there. I would also make sure that they got the pep-talk about why using foreach reduces mistakes, and why hash lookups are better than explicit positional logic or scanning arrays. (Hash lookups win on maintainability and performance.) I would consider a pep-talk about list-oriented ways of thinking being good.
And then follow up with code reviews. Ding people for using explicit for loops. Ding people for using positional logic when they didn't have to. Ding people for any scanning logic which isn't justified. (Unjustified essentially means that overall it is bad algorithmically.) Point out where they can use hashes. Oh right, and be sure they use strict.pm.
|
---|