Let's organise a free teach-in
djk at tobit.co.uk
Sat Feb 17 22:11:59 GMT 2007
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 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
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.
More information about the london.pm