Like all good answers, it depends.

One of the strengths of Perl as it relates to learning the language is that it's possible to get a frightening amount of work done with a very small subset of the language.

A bigger strength is that there's usually a much more concise and efficient way to do it. Showing less experienced programmers these techniques is a very good thing.

The trouble is, how do you teach them to recognize when one solution is better than the other? How do you help a new programmer discern between different approaches?

Take a look through the Perl FAQ sometime with a beginner's eye and see if you can figure out *why* underexperienced coders are drawn to symbolic references and other easy-to-do-but-hard-to-do-appropriately things.

One of the few shortcomings of the assembled documentation is that it sometimes doesn't explain *why*. That's something I had to learn through experience (making mistakes in Perl and programming a half dozen other languages).

No matter what kind of answer you give, you're depriving the supplicant of some of the benefit if you don't go into why things are done the way they are. Experience is a good teacher, but it's not a gentle one. Reading the documentation is very good, but it's no substitute for already knowing how to program in general.

(spurred on by this line of thought, I'm thinking of writing something like 'Common Mistakes of Beginning Programmers' along the lines of Common Regex Gotchas or whatever I called it way back when. anyone interested?)