Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Creating an Intermediate Perl Programming Curriculum

by Steve_p (Priest)
on May 03, 2004 at 21:13 UTC ( #350136=perlmeditation: print w/replies, xml ) Need Help??

The place where I'm consulting now is thinking about bringing in someone on site to teach an "Advanced Perl" class which will have some advanced topics like "make sure you use strict". It also introduces Perl OO before talking about references. Natually, this raised several red flags with me. So, I was thinking about what would be the essentially things they should learn. The level of most of the Perl programmers is beginner. They can write scripts that execute a query through DBI and are able to format the results. A few of the more advanced programmers have dabbled with objects. Regular expressions are rarely used. Most have learned to use strict and warnings since I don't sign off on QAs without them.

Anyways, I've come up with a preliminary list of things that seemed appropriate to cover. They include:

  • Using the standard Perl functions and modules effectively
  • Common Perl idioms
    • slurping files (and when you shouldn't slurp)
    • Schwartzian Transform
    • foreach vs. for
  • Regular Expressions
  • References
    • How and why
  • Creating modules
    • What does use really do?
    • Steps in creating a module
    • Exporter
  • Unit testing with the Test:: modules
  • OO Perl
    • The basics of OO Perl
  • Useful (or essential) CPAN modules
    • Using CPAN
    • The usual supects (i.e. LWP, XML::,etc.)

I'm thinking that what I have above would do a good job at taking relatively beginner Perl programmers to the next level. My biggest concern, however, is that I'm missing something. Does anyone see anything that I'm missing or something they think is out of order or something that you're wondering what I must be thinking? I'd appreciate any input you all can give.

Replies are listed 'Best First'.
•Re: Creating an Intermediate Perl Programming Curriculum
by merlyn (Sage) on May 03, 2004 at 21:25 UTC
Re: Creating an Intermediate Perl Programming Curriculum
by hv (Parson) on May 03, 2004 at 21:48 UTC

    (In no particular order ...)

    • How do I find things out?
      • online docs, perldoc, grep
      • people
      • mailing lists
      • usenet
      • websites
      • search engines
      • books
      • which to use when, and how to use them effectively
    • how to deal with people
      • how to ask a sensible question
      • how to become part of a community, and the value of doing so
      • what information to include
      • what information not to include
      • choosing a subject
      • asking in the right place
      • following up
    • How to debug a program
      • warnings
      • strict
      • the test suite
      • adding temporary diagnostics
      • modules: diagnostics, Carp, Data::Dumper, Devel::Peek
      • the debugger
      • the source code
      • knowing the style of code you write
      • see "How do I find things out" above
    • How to think when writing a program
      • top down: how to decompose a problem into smaller parts
      • bottom up: routines you know you'll need
      • middle out: write the hard bit first
      • OO: what are the objects?
      • making things readable
      • making things reusable
      • refactoring
      • (many others, pick what's suitable ...)


      <shameless type='plug'>

      modules: diagnostics, Carp, Data::Dumper, Devel::Peek

      I must admit my hopes are such that one day people will include DDS in that list, especially when that list is intended for debugging. DDS is much more accurate than DD, easier to read, and now that I provide a 'DDS' alias much easier to type too. :-) In addition I'm working right now on a ':Peek" export tag that will include the standard Devel::Peek stuff as well. :-) So that

      use DDS ':Peek';

      will do more or less the same thing as

      use Data::Dumper; use Devel::Peek;

      The only problem is I want to load Devel::Peek dynamically and export Devel::Peek::Dump as Peek(), but i havent worked out how to do it without changing the refcounts of the arguments yet. Ill figure it out soon, and then expect to see v 1.11 with Peek support included.


        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi

Re: Creating an Intermediate Perl Programming Curriculum
by hardburn (Abbot) on May 03, 2004 at 21:25 UTC
    • I wouldn't have the ST in there at all, or I would make it one of the finishing things. It's not the easiest thing to get your head around (though once you do, you won't have many problems using it).
    • Using modules should come before creating modules
    • One vastly overlooked area of Perl tutorials is handling error messages. Error messages that spew out of perl can be quite intimidating, and sometimes completely wrong. Knowing when perl is just plain full of crap is a skill which I doubt anyone has mastered, but the process could be helped along by a few good examples.

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

Re: Creating an Intermediate Perl Programming Curriculum
by talexb (Canon) on May 03, 2004 at 21:44 UTC

    Having listened to Schwern do a lightning talk at YAPC 2001 about how the AUTOLOAD syntax was broken for a particularly odd case of inheritance (I think my brain started to melt after the first minute), I've generally been successful at avoiding AUTOLOAD. Unless your folks are fairly up to date on OO programming, I'm not sure they'll get AUTOLOAD, which seems to magically instantiate object methods as necessary (shudder).

    Instead, I'd recommend something like Class::MethodMaker -- that's pretty cool OO stuff, and it's something they can probably use right off the bat.

    I'd also highly recommend some time on Perl one-liners and on the Perl debugger.

    Alex / talexb / Toronto

    Life is short: get busy!

Re: Creating an Intermediate Perl Programming Curriculum
by Sandy (Curate) on May 03, 2004 at 22:01 UTC
    What are the skills of the students with respect to general programming skills?

    I have had the misfortune of taking a few too many "C++" courses that focussed on... "how does a for loop work". Having programmed for 20yrs, I know how a for loop works, even if I don't know the C++ syntax.

    Then one day, I took a course for C++ aimed at those people who were truly proficient programmers, but who had never touched OO (or C++). That is when I truly learned something.

    My moral... before you decide on your curicullum, decide who you want to teach to... perl newbies, but programming 'aware' ... or perl relative newbies and programming 'sorta'.


Re: Creating an Intermediate Perl Programming Curriculum
by toma (Vicar) on May 03, 2004 at 22:08 UTC
    I agree with skipping AUTOLOAD and the Schwartzian Transform, and adding something on Data::Dumper and perhaps the debugger. Using ptkdb results in the fastest learning. I asked instructors at a conference BOF meeting why they didn't use ptkdb for teaching, and the only reason cited was the difficulty of installing ptkdb on the local machines before the class.

    A debugger gives you a chance to step through a program and quickly hover over variables to show how they have changed. They are good for learning and reading code, even if your own day-to-day coding challenges don't benefit from using them.

    For objects, I would just teach how to create a hash and bless a reference to it. Then show how to use references as hash values to make a more complex object. I struggled with teaching various automatic-object-creation modules until I found that the hash explanation works better.

    I also like to explain common design antipatterns to intermediate programmers, since they tend to be familiar with them! 'The Big Ball of Mud' is a good story to go along with the learning about object-from-hash-reference.

    It should work perfectly the first time! - toma
Re: Creating an Intermediate Perl Programming Curriculum
by geekgrrl (Pilgrim) on May 04, 2004 at 15:47 UTC
    Two major things to teach: References and Modules.

    I find that one of the most important concepts in Perl is references. So many decent Perl programmers never take it to the next level by getting their heads around this one. Also, writing modules, whether OOP style or not, is an important skill to take the beginning script writer to that of a Perl programmer with mad skills.

    I have taken many beginner scripts - the style where they are required in another program, and turned them into simple modules. It makes so much difference and greatly extends the usability of the code.

    Also, I second the motion of teaching Data::Dumper. This is the best module in the entire world. Also - it's handy for understanding references.

Re: Creating an Intermediate Perl Programming Curriculum
by cLive ;-) (Prior) on May 04, 2004 at 08:14 UTC

    # foreach vs. for

    Err, and the fact that they are exactly the same, just easier to read, depending on context. For example, these just don't flow through the brain as comfortably:

    foreach (my $i=0; $i<10; $i++) { print "$i\n"; } for my $i (0..9) { print "$i\n"; }

    But I know what you mean :)

    cLive ;-)

      Yes, that, and the ability to use for in a single statement like if and unless. For example:

      s/foo/nofoo for @array;

        You can use foreach in the exact same manner. They are synonyms. One can always be used in place of the other:

        $ perl -le 'print foreach 1, 2, 3' 1 2 3
Re: Creating an Intermediate Perl Programming Curriculum
by cLive ;-) (Prior) on May 04, 2004 at 08:20 UTC
    more thoughts...
    # general rule 1 use strict; use warnings; # general rule 2 #!/usr/bin/perl -T - unless you know you don't need it # general rule 3 Don't just use -T and then untaint everything with /(.*)/ - unless you know why # CGI Rule 1 #!/usr/bin/perl -T use strict; use warnings; # CGI Rule 2 (when testing) use CGI::Carp 'fatalsToBrowser'

    cLive ;-)

      # CGI Rule 3 (when in production) # never ever use CGI::Carp 'fatalsToBrowser';

      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
         -- Rick Osborne

      Edit by castaway: Closed small tag in signature

Re: Creating an Intermediate Perl Programming Curriculum
by zentara (Archbishop) on May 04, 2004 at 13:05 UTC
    I'm probably not the "most qualified" person to tell you how to teach, but from my experience, just show alot of working examples.

    Most people are NOT able to grasp details right away, so show them alot of working code, walk thru the code step by step, and tell them where to read about the details.

    Most people feel they "really gained something", if they have a few code samples which they can take, modify and run. It empowers them, and "wets their pallette" so they want to learn more.

    I'm not really a human, but I play one on earth. flash japh
Re: Creating an Intermediate Perl Programming Curriculum
by nmcfarl (Pilgrim) on May 04, 2004 at 16:34 UTC

    So what brings a beginner up to the next level? Well you have the core, better regexs, references, module use and creation, and OO modules.

    The one thing that I don't see listed but think is important is list processing. The appropriate use of map and grep can make programs shorter and much more readable. I think it's a core skill that is often overlooked.

    I definitely recommend module use be stressed before you move on to module creation. But when you do move on I find it useful, depending on the audience, to mix OO with the modules and packages discussions. The implementation of OO Perl makes it ideal for clarifying, questions on modules and packages. It also allows you to put off dealing Exporter( and it's difficulties), while still getting working, idiomatic perl modules written.

Re: Creating an Intermediate Perl Programming Curriculum
by bronto (Priest) on May 04, 2004 at 16:58 UTC

    Nice topic :-)

    To all other monks said I'd just add a few things. First, about OOPerl you skip from basics to AUTOLOAD directly. I believe that they should first understand how AUTOLOAD works, even without knowing about objects; when coming to objects it will be clearer what they can do with it and, more important, they will easily get why if they use AUTOLOAD in OOP they also should define a DESTROY method (in general)

    Second, I'd teach them when to use objects and when leave them alone. I am dealing with another programmer's script that uses classes as... "configuration objects" (I don't even know how to call them!!!), e.g.: my $dir = MyProg->workdir ; my $login = MyProg->login and so on; those "classes" don't even have a constructor!!! Even if this could be not completely wrong, I personally consider it as really-bad-style, definitely. And when I need objects to get configuration variables I use AppConfig or similar modules (which you could also like to illustrate to your students).

    My 2 cents (of Euro:-)


    The very nature of Perl to be like natural language--inconsistant and full of dwim and special cases--makes it impossible to know it all without simply memorizing the documentation (which is not complete or totally correct anyway).
    --John M. Dlugosz
Re: Creating an Intermediate Perl Programming Curriculum
by parv (Vicar) on May 05, 2004 at 07:31 UTC

    One thing, not explicitly mentioned, that everybody should learn, i think, is seeing how a regex is matched and parsed via -Dr switch (perlrun(1)).

    If/When you cover Schwartzian Transform (ST), consider covering a modified form of ST: Guttman-Rosler Transform. Around those two transforms, you could (re)introduce (un)pack functions.

    After the coverage of references and around coverage of AUTOLOAD, symbol table manipulation, say for creating methods/subs, does not seem too much of a stretch.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://350136]
Approved by Sidhekin
Front-paged by bronto
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (4)
As of 2020-05-31 04:32 GMT
Find Nodes?
    Voting Booth?
    If programming languages were movie genres, Perl would be:

    Results (173 votes). Check out past polls.