views:

692

answers:

11

I was bullied into giving a four hours Perl training. What topics should I cover?

There is a similar question already, but I found that question to be vague, and the answers equally so. So I'll be more specific in what my outline is.

To me, Perl is about getting things done. My Perl scripts are one-shot scripts intended to solve specific problems, mostly related to processing files to do basic data transformation, aggregation and filtering.

I do intend on covering CPAN just enough to teach people how to search for domain-specific libraries and use them. I also intend to cover plain regular expressions, but nothing more sophisticated than that, as I don't believe advanced Perl's regex can be taught in a time-efficient manner.

So, given this domain, any tips?

Edit:

The people I'll train are experienced programmers who also have shell scripting knowledge. Also, I do not need to impress them with the power of Perl -- they are impressed already, that's why they bullied me into giving this training.

+2  A: 

Have a look at the answers for How can I impress people with perl's capabilities

mirod
Done. Actually, I don't like it. I'm not trying to impress anyone -- these guys WANT to know how I do the stuff I do in Perl. And my CPAN usage is pretty low -- particularly given the severe restrictions on installing stuff in our servers.
Daniel
+2  A: 

I'd probably include a contrived "investigating a problem" scenario, where you start with using Perl to just count something up with a one liner, then realize you want to extract some slightly more complex statistics.

Kevin Peterson
Obligatory: http://xkcd.com/208/
therefromhere
+2  A: 

Here's a list of starter topics:

  • Perl variables: scalars, arrays, hashes
  • Some useful built-in functions like map, grep, join, split, print, etc
  • Writing your own subprocedures
  • Regular Expressions
  • Basic file IO including tricks like while (<FILE>)

EDIT: It's good to work towards a goal. If you're trying to show the power of Perl, pick a relevant problem to solve. Try to have your students/colleagues/coworkers have some working Perl scripts at the end of the 4 hours that parse some text files or do something related to your actual work.

Eric
If the audience is made of programmers, I would avoid that. In 4 hours they would just get the impression that the syntax is complex, and still have little idea about what you can do with the language. Showing CPAN explains how you can leverage (sorry!) the syntax and the existing modules to actually do cool stuff.
mirod
Actually, that is about what I had in mind when the time-frame was set to 2 hours instead of 4.
Daniel
So use the remaining 2 hours to get into useful CPAN modules. It's hard to get around a quick introduction to the basics of Perl. Maybe leaving out your own subroutines, but regular expressions are a must. The built-in functions are also a must for avoiding doing things the C way.
Eric
A: 

As the commenters have stated, your intended audience is the most important factor. I assume they are experienced programmers. I would try to demonstrate "getting things done" by choosing a problem from the audience's day-to-day job: For web developers, maybe some kind of a log analysis; For VLSI, looking for a specific electronic component in a circuit etc. After showing how to solve the problem with a specific Perl script, you can go over the language components used in the solution, and then generalize a bit. Setting the new language in a familiar environment should make the ideas more reachable. You can also use a familiar programming language, as in Perl for C++ programmers.

Yuval F
it's Perl, not PERL.
singingfish
A: 

I'd do three hours on the basics, scalars, hashes arrays, references, file tests, CPAN usage and very basic Moose for OO. Then I'd open it to the floor to do a group problem solving session using Perl for the last hour.

singingfish
I'd avoid Moose entirely, as it is not 1) part of Perl, 2) one of ten different similar systems under Perl, 3) isn't common at all in existing codebases, and 4) going to be muddying the waters as to what's Moose and what's Perl for a bunch of people in a beginning Perl class. Teaching Moose on day 1 would be like trying to teach people how to barrel roll a car off a ramp before teaching them how to shift.
Zenham
I'd mention it maybe even if you don't cover it then, because if you're doing OO perl at, there's really very little reason not to use Moose (don't listen to the performance FUD __PACKAGE__->meta->make_immutable solves most of that).
singingfish
I have nothing against Moose, but it's doesn't belong in a four-hour intro to Perl. Moreover, it's completely inappropriate for the "basic data transformation" described by the original poster.
Michael Carman
If you aren't going to spend a lot of time talking about Moose, there's no point in merely mentioning it. There's a lot to grok there, and even knowing Moose doesn't mean you don't have to know Perl's OO.
brian d foy
+2  A: 

Picking up Perl does a good job of providing a concise introduction.

Sinan Ünür
It's rather outdated though, eight years since the last update and three major Perl releases during which much has changed.
Zenham
+11  A: 

Four hours isn't much time. Keep it focused on your audience and target domain. I might start by presenting a sample problem (taken from one of your real-world scripts) and lead them through how to solve it using Perl. Along the way, introduce the concepts needed to solve the problem. You don't have to teach programming, just "this is how you do X in Perl."

Some specific items to cover:

  • strictures and warnings: Give them the tools to make coding & debugging easier right off the bat. It's easier to start with good habits than to break bad ones.

  • Perl's version of lint: perl -Mstrict -Mdiagnostics -cw <file> One of my favorite things about Perl is that the parse error messages are gloriously helpful, unlike cough C.

  • perldoc: They need to know how to find the answers to their questions. Be sure to include perldoc perl, perldoc perldoc, and perldoc perlfaq That should be enough to bootstrap them into learning everything else they should know about perldoc.

  • scalar vs. list context: This is an important concept in Perl and one that's unique to the language. It will probably seem strange to them, so spend a little extra time here.

  • variable types and sigils: Introduce scalars, arrays, and hashes. Tell them how scalars can be anything: floats, ints, strings (not just chars) and that conversion between strings and numbers is mostly automatic. Also note that sigils denote context, not variable type. (e.g. $array[2] not @array[2])

  • regular expressions: Indispensable for text munging, and a big part of why people think that Perl code looks like line noise/swearing/derogatory description of your choice.

  • references: You'll need these to create data structures.

  • core modules and CPAN: Reusing proven code is a Good Thing.

Michael Carman
+3  A: 

If you are gifted with skilled programmers as an audience, I would skip the classic "Hello, world", Variables, procedures, regex approach. They are all familiar with these concepts, especially if they have been scripting already.

You should ask yourself a whole different question: What can be done using Perl which will be way faster and more elegant than any other language?

Try to find examples that are relevant to the audience (read some of the answers here). Are you handling images in your company? write a neat little script using imagemagick . Are you parsing anything like Excel? Do it with the appropriate module. Do you have a critical server in your company? Write a little script that pings it, and if there's no answer - sends an SMS to to someone. These are all (almost) one-liners in Perl.

The key here is finding a task which is both relevant to the audience and extremely efficient in Perl! You'll look like a magician, and that's the finest way to get people interested and curious.

Adam Matan
+4  A: 

You've got a motivated set of skilled professionals. Just about the best group of students you could ask for.

If I were teaching the class, I'd give a super quick overview and provide resources for the motivated to learn more. If you won't have a lab and lab time, I don't really see any other way to go--anyhow, a practical lab would eat all your time.

It is critical that you give your class the tools to find more info on their own.

Provide your class with an outline or lecture notes. Each topic should have links to resources for further reading.

Here's a list of topics, with references to the docs, or other sources where I could think of one.

Documentation and Help

  • Perldoc
    • Perl has tons of docs. A beginner needs a guide. See: How to RTFM
  • Finding help -
    • Perlmonks,
    • SO
    • learn.perl.org, etc.

The Perl Language

  • Scoping
    • Local (dynamic scope) vs Lexical scope (Coping with Scoping is good but a bit dated)
    • See Coping with Scoping
  • Context
    • List versus scalar,
    • Context propagation
  • Data types
    • Array Scalar Hash.
    • A list is NOT and array
    • list flattening.
    • See perldata
  • References
    • Anonymous constructors [] and {} - perlref
    • Code refs - perlsub
    • Reference counting and 'weak' references.
  • Regexes - perlre, perlop
  • CPAN
    • How to find, evaluate and install modules
    • using the cpan shell
    • Other tools: AnnoCPAN, Kobesearch, CPANPlus
  • Perl modules
    • Namespaces and package, perlmod
    • Symbol table, perlguts
    • Exporter - POD + perlmod
  • Objects

Additional Resources

  • Further reading -
    • Learning Perl
    • Perl Best Practices
    • Programming Perl
    • Higher Order Perl
    • Perl Testing: A Developer's Notebook
  • Suggested modules -
    • Scalar::Util
    • List::Util
    • Moose
    • DateTime
    • DBI
    • DBM::Deep
    • Devel::NYTProf
    • ptkdb
daotoad
+2  A: 

Start with Learning Perl and cut out the bits you don't want. Everything you mention is already in the book, and you can go through parts of it faster depending on the level of the audience. It even has exercises (and answers) that people can do on their own.

The trick in this situation is to get them started and let them go off on their own. Four hours is a really short time (and I say this as a person who's been teaching Perl in all sorts of situations). I'd give them:

  1. An hour introduction to the basic concepts of the language and a little homework to do over a couple days. This covers things like context, defaults, and the other things that makes Perl special.

  2. A couple days later, go through an introduction to CPAN without explaining how anything works other than following the examples. Show them some of the modules they will need.

  3. After that, spend some time writing a script in front of them so they can see the development process, including checking the docs, looking at CPAN Search, and whatever else you do for real.

With experienced people, this is just the kick they need to get moving. The rest they can pick up on their own.

brian d foy
+2  A: 

I used the GFDL Learning Perl the Hard Way book. It is designed for seasoned programmers in an other language that want to be rapidly up-and-running in Perl.

2 majors points :

  • It doesn't dwell into algorithms and CS background. It starts right in the middle, w/o seatbelts.
  • It isn't filled with write-only code samples that highly contributes to the Perl reputation of cryptic code that non-perl-litterate usually have at the beginning.
Steve Schnepp
I'll look that up. I can't get it fast enough, but I might well recommend it.
Daniel
It's a free book, good!
Daniel
I loved it. In fact, it is very close to what I was doing already, so it complements well my material. And, to boot, it taught me one thing already. :-)
Daniel