Let's organise a free teach-in

[Iain Tatch]

On 17/02/07, Edmund von der Burg <evdb at ecclestoad.co.uk> wrote:

>   * code design - thinking about the problem before launching into the code.
>   * writing modules - put as little code as possible in scripts, as
> much as possible in modules (and why).
>   * plugins - you can have bits of code that extend other code without
> requiring any changes to it.
>   * OO - each plugin inherits from the core module and so has access
> to generic functions
>   * testing - each plugin should have tests, and be written in a
> testable way (test first even)
>   * documentation - the 'help' plugin should be able to parse the POD
> of the other plugins to generate help pages.
>   * Don't Repeat Yourself - there should be no duplication of code.

I agree, these *are* all admirable qualities and concepts for a good
Perl developer to have.

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).

Iain

[1] Or the "early 1980s", to use the vernacular.  Although good OO
techniques might have formally developed a little later.