• EVERYTHING HAS USE STRICT AND USE WARNINGS/-w ... Don't go any further unless this is in your curriculum. I know that's being an ass, but I feel that strongly about it.
• $_ and @_ and how they're the defaults. (This is a big one!)
• statement modifiers foo($_) while (1 .. 10);
• grep and map - Spend a lot of time here!
• range operator as a boolean short-circuit
• regexes as pretty much anything (booleans, shortcircuits in ranges, etc)
• Using regexes to parse
• Using substr to parse
• References. Use the pointer concept to start, but break away from it ASAP, as references are NOT pointers.

As for getting them to think in Perl, force them into text-manipulation. That's where Perl started and that's where it shines. Ask them to find all the occurrences of a regex-match in a file. Have them do it in their favorite language, then in Perl. Show them 3-4 different ways in Perl, starting with the most C-like, then moving slowly to Perlisms. Try and remember how you discovered things like:

LINE:
while (<INFILE>) {
    next LINE while /Foo/ .. /Bar/;
    chomp;

    # Do stuff here.
}
[download]

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

As for getting them to think in Perl, force them into text-manipulation. While this is very good advice, I would also urge them to think in terms of list manipulation as well. NOT linked-lists, NOT list-like-arrays, but as mentioned above, the importance of the functions of map, grep, sort, for/foreach, and how one can effectively do loops without a counter, unlike C, C++, or Java. I remember when golf problems started to show up here that many were better solved thinking about using lists and taking advantage of map and friends, than to break it down in any other fashion. Absolutely positively make sure they understand the usefulness of the Schwatzian Transformation as well for sorting complex data items.

I would almost go as far as introducing elements of functional programming, but that might be too much for a learning class, but it's very important to stress the list aspect of perl over anything else.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
It's not what you know, but knowing how to find it if you don't know that's important

Now that's a thought! Why not, as bonus problems, introduce a few of the easier golfs? Do something like "Try and solve this under 100 characters. The best I've seen is 53" and have them go at it. Then, explain a few solutions, including the best one. I know that I learned a ton of idioms, especially list-processing, through golfing.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

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.

I went through a similar experience a couple of years ago at a client, bringing C programmers up to speed on Perl. The most important thing to keep in mind is that it will take time. No matter how good the material they're learning from, no one will start using Perl idiomatically until they write several good-size chunks of code. Don't be in a hurry (and see if you can convince your boss of that!)

That said, one thing I found particulary useful was the points in the "perltrap" document that were aimed at C, awk, and shell programmers. These people had worked with all three (Korn shell) and seemd to stumble on every single one of these.

Another area that really helped was talking about loops, labels, and blocks. For that I just used some examples straight out of perlman:perlsyn, particularly the section on foreach loops. Those really seemed to resonate with people.

One exercise that made the light bulb go on for a lot of people was emphasizing how, in Perl, you could manipulate an array rather than use indices into it. My example was: given an array of integers, calculate the sum of the elements doubled. First I showed a "typical" C-ish solution:

# suppose @myvec is an array of integers.
my $sum = 0;
for (my $i = 0; $i < scalar(@myvec); $i++)
{
    $sum += 2 * $myvec[$i];
}
[download]

my $sum = 0;
foreach my $i (@myvec)
{
    $sum += 2 * $i;
}
[download]

my $sum = 0;
$sum += 2 * $_ foreach @myvec;
[download]

HTH

In short, I'm much too lazy to duplicate the existing documentation for this and I suggest you be lazy as well.

I've actually got a course that I call <http://www.iterative-software.com/training/idiomatic-perl.html>Idiomatic Perl I've run it a few times under circumstances that sound very similar to yours and it's proved very popular.

The most popular parts seem to be:

• The importance of use strict and -w
• foreach, grep and map
• Overview of modules in the standard distribution
• Overview of useful CPAN modules
• Writing your own modules
• Where to go for more information

I'm hoping to run a cut-down version of the course as a tutorial at various Perl conferences next year.

"The first rule of Perl club is you don't talk about Perl club."

Most of it is online in PDF format but it is well worth the cashola.

• CPAN - what it is, how to use it
• The Perl community - user groups, e.g. PerlMonks
• Open Source - Benefits

When I am planning some major code, one of my first thoughts is "How much of this has already been done and available on CPAN ?" This can often change my approach to the coding depending on what aspects of the problem are already available as modules.

I have found this quite different to the approach of someone who has been brought up with e.g. Visual C++ as a working language.
--
Brovnik