Let's organise a free teach-in

[Dirk Koopman]

Iain Tatch wrote:
> 
> They are also admirable qualities and concepts for a good [VB | Java |
> Ruby | etc] developer to have -- they're basic principles of software
> development that have been taught since time immemorial[1] in any half
> decent programming or software engineering course.
> 
> To answer Tim's original question, I think the only fully Perlish
> thing that needs to be taught is CPAN.  The knowledge that someone
> somewhere has already provided most of the solution to your problem is
> one single thing above all others that makes Perl such a powerful
> tool.  Apart from that it's just a case of learning basic programming
> concepts, a rather idiosyncratic syntax, and good software development
> methodology (as above).
> 

CPAN is a wonderful resource. However the code within it is of extremely 
variable kwalitee. Useful to know, but as it is mentioned early on in 
nearly every perl book; frankly if you have not read and understood that 
CPAN is always worth a look, then you are probably not suitable for this 
course.

The difference between a programmer and a perl programmer is someone who 
actually understands perlish ways. Sadly, I am old enough to think that 
OO is not the ultimate answer to everything. I would concentrate on 
making sure that people actually understand basic things like:

  * context (what does it all REALLY mean, including wantarray et al)
  * regexes (esp. the more obscure bits that involve collections
    backtracking '/[eg]' etc)
  * the use of eval (the joys and dangers of "live code")
  * the real differences between use, require and what import() does.
  * INIT, BEGIN etc
  * AUTOLOAD, DESTROY and symbol tables
  * globs, what they really are and how they can be used.
  * closures (how to recognise one and when to use them)
  * how to poke about inside %INC and friends (+ why you might want to)
  * how to write perl extensibly.
  * special "features" like why 'my $a = 23 if $foo;' doesn't do
    what normal programmers expect.
  * DWIM, its joys and pitfalls.
  * benchmark/profiling, how to do it.
  * debugging efficiently.

  * only then maybe taking these things and applying them to DB[ID]*,
    CataPole or other clever package du jour.
  * and how perl does basic OO, tricks and tips and why you *might* then
    want to use some package or other that papers over some of the
    perceived OO cracks

In other words perlish things that make the language what it is and that 
you only glean after years nursing a sore head.

Dirk