What should I teach a beginning Perl programmer?

Answer 1

Definitely show them how easy it is to use regular expressions in Perl.

Answer 2

That's basically a task-oriented question.

If they are to use it for parsing, show them how easy manipulating STDIN and file i/o is.

If they are going to use it for databases, show them how to get hashrefs from query results and that should wow them.

Perl usually has some way to make just about any task super-quick. Pick out the task they need to do.

But definitely teach them to use my and local. Stress the importance of my and that will make their experiences happier.

Answer 3

If he’s an experienced programmer, he might like Smart Comments, POD, closures, the -d:DProf switch and dprofpp, one-liners, Perl Critic, Moose, __DATA__ or map. (Which is a crazy mix indeed.) I’d explain to him right from the start that Perl is a language with a lot of magic, but that he is free to choose when to stick to simple code and when to draw a wand. Experienced programmers are not afraid of choices :-)

Answer 4

Experienced programmer or not, in 30 minutes you can't pretend to teach anything, let alone Perl. At most you can try to enlighten him with some cool one-liners (provide their full-bloated Java counterpart, for comparison).

Answer 5

We wrote a whole book on that called Learning Perl. Check out the table of contents.

This book is a product of teaching people Perl since 1995. It's not geared to any particular application, and shows people the parts of Perl that they'll use for 80% of their Perl programming. We updated it for Perl 5.10, and include sections on using CPAN.

Good luck, :)

Answer 6

I'd cover lists and hashes first. (Pathologically Eclectlic Rubbish Lister, remember.) Show him how much prettier foreach is than a C-style for.

If he's coming from C/C++ it would be good to refer him to http://perldoc.perl.org/perltrap.html or 'perldoc perltrap.' It contains the most obvious differences to be aware of.

Answer 7

I agree with some of the other commenters that it truly depends on the type of task that Perl is being used for. Is this person a Windows system admin? Then I'd cover using WMI from Perl (scriptomatic would be a good resource here).

I'd grab a copy of Oreilley's "Perl Cookbook", and find some interesting topics out of there. Here is a link to the book here: link text

One of my favorite things in Perl is how easy it is to compare lists, looking for unions, intersections, or differences in unique lists (recipe 4.9 in Perl Cookbook). Helps you appreciate the power of Perl.

Answer 8

It depends on what kind of programming this 'Experienced Programmer' is experienced in.

If they've done much shell programming, they'll probably be impressed by Perl in its super-awk personality - do some practical extraction and reporting by using regexes and templates.

If they're more like C programmers who like to work with complex data structures, show them how easily you can whip up a hash of hashes, and how quickly the resulting code executes.

... and so on.

Answer 9

The idea that popped into my head, was to have them transfer information from one format to another. For example, getting xml data, and transfer it to JSON, for use on a web-page.

cpan JSON XML::Simple

use strict;
use warnings;

use JSON;
use XML::Simple;

my $data;
{
  open( my $file, '<', 'filename.xml' ) or die;
  $data = XMLin($file);
  close $file;
}
{
  open( my $file, '>', 'filename.json' ) or die;
  print $file to_json( $data );
  close $file;
}

Answer 10

Perl has two things that are likely to be foreign even to experienced programmers, so those should perhaps be mentioned early on so they don't run away screaming.

Context: Nearly every function in Perl has 2 behaviors. When called in a "scalar context" and it does one thing, when called in a "list context" it does something else instead. This may seem weird and strange (and it is, in machine languages) but is simply the natural language concept of "singular" and "plural" applied to a programming language.

Variables: Perl has 2 completely different and separate systems of variables. Lexical variables (my) and package variables (our). Lexical variables are "normal" if you've used most any programming language. Package variables (i.e. dynamic variables) are strange, unless you've used something like Lisp. "Always prefer lexical variables over package variables, except when you can't."

Answer 11

Just my 2c, but in relation to CPAN, how about you pose them the problem of splitting English text into sentences?

At first, that seems simple: a sentence is a string with a period at the end.

But after a moment's thought, a programmer will find there are all kinds of complexities which arise. Periods can be in the middle, if there are decimal numbers or abbreviations; sentences can end with other things, like "?", "!" or "..."; 'a period followed by a space' doesn't help either because what about EOF?

Long story short, when it comes to Perl, someone else has thought of everything on that list and more. So you use Lingua::EN::Sentence.