I would also stay away from discussing best practices such as using qx() instead of ``, and save that for after they are up and running. It would also be wise to have them all read Perl Best Practices - but again, after they understand the basics.

As they are coming from stricter languages it is a very fair question to ask about the difference between single and double quotes. In some languages that difference is used for creating a string, or for a single character. I agree with your supervisor - don't teach alternative quoting. It just isn't important enough at this point.

Above all make sure you teach them to always use strict and warnings. They will feel more comfortable if the language doesn't overdo the DWIM behaviour.

Take this as an opportunity to expand your own knowledge by teaching others. There are countless things that everyone "knows", but that they do not know how to explain. Discovering how to explain them often teaches you a great deal.

I would start them out with lists, arrays, and simple constructs like foreach. Keep your examples concise and avoid anything that looks magical, or you will reinforce whatever stereotypes they have heard about perl golfing, and they will focus on the trees and miss the forest.

An example for foreach

# Basic example
my $sum = 0;
foreach my $number (1,2,3,4,5) {
  $sum = $sum + $number;
}

# A little better
foreach my $number (1..5) {
  $sum += $number;
}

# Probably shouldn't show this one
$sum += $_ for (1..5);
[download]

I would stay away from showing them map or grep initially unless you're dealing with someone with lisp experience.

+= and all the C derived syntax ought be bread and butter to C/C++ folk. Regexen, map, grep, for, if as a statement modifier and hashes are where the power and succinctness of Perl are.

I showed a workmate (who has some Perl knowledge) some code that looked like:

    my $token = 'do_' . lc NextWord (\$line);
    
    die "Internal parsing error. $token is not recognised\n"
        if ! $self->can ($token);

    return $self->$token ($line);
[download]

that allows me to add code like:

sub do_hi {
    return "Hello World";
}
[download]

and he was blown away. Showing the same code to a C++ only workmate evoked the response "Oh, that's just dynamic dispatch" (which I'd already said). The moral is, they will either get it or they won't. When they get it, a whole new world opens up. If they don't, t'aint nothin you can do.

You have a better chance showing things Perl is good at, string processing in particular (where other languages are clunky) to inspire interest.

Don't sweat syntactic details, those can be worked out when you've captured their imagination. Go for the bigger picture with a few examples of where Perl shines. Remember: regexen and hashes first, list processing (for, grep, map) second, then syntactic sugar (statement modifiers and string interpolation).

I'm not much of a teacher. But if I were teaching a brief overview of Perl, I would probably follow the outline of perlintro. It's all there:

• What is Perl?
• Running Perl programs
• Basic syntax overview
• Perl variable types
• Variable scoping
• Conditional and looping constructs
• Builtin operators and functions
• Files and I/O
• Regular expressions
• Writing subroutines
• OO Perl
• Using Perl modules

The section on OO Perl is very brief, mostly just mentioning that it's beyond the scope of the article, but that the "Using Perl modules" section would at least address how to deal with OO modules.

That ought to be good meat and potatos to get the group started. The next day, pick one of the topics from perlintro, and dive into it in greater depth. perlsyn and perlsub may be a good basis for the second and third sessions. perlretut or perlreftut might make a good week-two discussion.

these people program in C/C++, Fortran, C-Shell on a regular basis, and allegedly sed and awk.

As a group, or individually? i.e., did they all have a common background?

If they didn't, it can be very difficult to teach. I remember taking a 'C as a second language' class during my undergrad. It was still a rather intensive course (I think it was 1, maybe 2 credits, but still had as much in-class time as any non-lab course), but they skipped the obvious stuff like the concepts of constants and variables. But they couldn't expect much more than that from anyone.

The problem was, we didn't all have common experiences -- there were people who had Basic, Pascal, Ada, Fortran, etc, and no one language in common -- so the teacher couldn't speak in idioms that would be universal to all people.

I'd suggest that you specifically try to do a overview of Perl for C programmers, and then one of Perl for Fortran programmers, etc. Trying to mix the group too much is going to get the one Cobol programmer tossing questions at you that you're not prepared for, which then bores the rest of the people, and then people stop paying attention, and it turns intoa big waste of time for most people.

So my suggestion -- start small. Specifically compare Perl to a language that the audience already knows. Build on things incrementally, and don't expect sudden converts from a quick tutorial. Instead, leave some nagging thoughts in their mind about where Perl excels, and try to get them to come and ask you more about Perl when they come across those sorts of situations.

If you have to, you can do the late night TV pitch:

1. Describe exagerated problem
2. Provide solution
3. Ask how much they'd expect to pay
4. Give them a low cost
5. Hook them with the 'wait, there's more' free thing.

Okay ... maybe not ask them how much they'd pay ... maybe ask them how many lines of code they think it'd take.

I came myself from Fortran / C / C++ to perl.

The best things of Perl at all for me while learning were the hashes (it took a while to get the great advantage of Perl hashes in daily use also i was using simular structures for special cases in C++ before) and the power of regular expressions.

I know, regular expressions are not the best to start with and it took me a while too to learn enough about them to use them, but these two points were - among much others - the brightest moments where I was pleased to use Perl.

Another fine thing is to show them both forms of the for loop. It's nice to use the C form while starting and to switch to the much nicer Perl form later on. But all these tips are a lot subjective. Perhaps this could give you a hint? Good luck anyway.

One thing I'd add is a three minutes overview of what CPAN is. Mention how easy it is to use and that it is the extensive public library that is the Standard, which other languages try to reach. (Show -- don't teach -- a list of example modules. E.g. Inline, Mechanize, treating text files as an array of lines, etc.)

Also tell them the books to start with.

Update: What I tried to say -- you should (a) give the students an idea of the next step and (b) show them some powerful uses which are simple to implement.

I agree about the CPAN thing.

Perl's a programming language. They've seen programming languages before, they'll see them again.

But I bet they have no idea how enormous CPAN is and all the weird and wonderful stuff that's in it.

Taking something like Lingua::EN::Sentence for instance.

Throw this question out to the class --

What's a sentence? Anything up to a full stop? Nope, not good enough. Anything up to a full stop followed by a space?

Maybe ... maybe not.
        ^^
[download]

OK then, full stop, space, uppercase letter? I'll ask

Mr. Jones
  ^^^
[download]

if he thinks that's smart enough an algorithm. He works for

I.B.M. I think.
     ^^^
[download]

"Wow, that's a lot harder than it looks."

Oh yes and we forgot about quotes, question marks and exclamations.

The point of all this being that someone has sat down and thought really hard about all those things for a really long time and come up with Lingua::EN::Sentence so they don't have to. Plus of course it's easily extensible in case they find something it doesn't catch.

use Lingua::EN::Sentence qw( get_sentences );

$text = "
I agree about the CPAN thing. Perl's a programming language. They've
seen programming languages before, they'll see them again.
But I bet they have no idea how enormous CPAN is and all the weird
and wonderful stuff that's in it. Taking something like
Lingua::EN::Sentence for instance. What's a sentence? Anything 
up to a full stop? Nope, not good enough. Anything up to a full stop 
followed by a space? Maybe ... maybe not. OK then, full
 stop, space, uppercase letter? I'll ask Mr. Jones if he
  thinks that's smart enough an algorithm. He works 
for I.B.M. I think. \"Wow, that's a lot harder than it 
looks.\" Oh yes and we forgot about
quotes, questionmarks and exclamations!";

my $sentences = get_sentences($text);    ## Get the sentences.
foreach my $sentence (@$sentences) {
    print 'SENTENCE: ', $sentence, $/;
}
[download]

---




($_='kkvvttuu bbooppuuiiffss qqffssmm iibbddllffss')
=~y~b-v~a-z~s; print

CPAN is useful for telling people that there are lots of great libraries that make it much easier to write complex programs that do magical things without having to write hundreds of lines of code oneself. CPAN is not something you can teach somebody about in his first-ever brush with Perl — at least, not effectively.

First, teach enough Perl to be able to use modules without actually talking about CPAN or module use. Next, teach how to use core modules that come with your Perl distribution, because using modules is almost like using a completely different language embedded within Perl. Third, teach how to create modules. Finally, after all of this, teach people how to use CPAN.

Get it in a different order, and you're likely to just sow confusion. That, at least, is my experience.

For a long time, my impression of CPAN was that it was more work than it was worth. This is because I was being pushed toward CPAN before I had the knowledge basis to be able to leverage it for any positive ends. Don't let my experience be the same experience your students have.

CPAN is an excellent resource. You're only doing someone a disservice if you introduce him or her to CPAN without first familiarizing him or her with enough Perl to be able to get any net benefit. By the same token, when you're helping someone migrate from lifelong Windows use to Linux (for instance), don't start with teaching how to compile kernel modules. Start with the installer and the package manager. Even if you believe that installing everything by compiling from tarball is the One True Way, you're going to run into real difficulty training someone unless you can find a way to teach compiling from tarball as an installation practice without taking them away from Windows first. Learning works best from within a context wherein something (almost anything) is familiar. The more that's familiar, the quicker the bits that aren't can be learned. Familiarize students with the basics before tackling the more complex stuff: teach how basic loops and variables work in Perl before tackling CPAN.

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

don't be confused about it. I had similar experiences when I gave courses (Statistical Software ->SAS,SPSS) for programmers that started with a "short overview". Usually these very intelligent people feel uncomfortable with something they can not grasp on first sight.

Maybe you answered too many questions in the beginning?