Re: Learning the Deeper Secrets of Perl

[adamk]

Write a CPAN module.

Write a CPAN module.

Write a CPAN module.

I'm saying this three time so that you will remember it.

In all seriousness, finding a topic that interests you that has not yet been solved, and then dealing with all the issues of naming, API design, sane implementation, best standards coding, writing for maintenance, documentation, proper unit testing, packaging, PAUSE, maintenance and bug reports from users, cross-platform compatibility and all the other things that come from doing a CPAN module (or three) will help to push forward your ability a lot further than you could imagine.

Nobody knows ALL the tricks of the perl syntax. At some point you are going to realise that you probably know "enough" of the core of writing perl code.

Once you have that covered, it's the higher order things that you need to be looking at. The standards you will need to follow and the issues you need to deal with in order to build and publish CPAN modules (and do it PROPERLY) are going to help you in all your perl coding.

Learning to write CPAN modules is learning to truly encapsulate properly. To solve certain problems and put them behind you and move onto more difficult problems.

Not to mention that for just about every single well paid senior perl position I've seen advertised one of the first questions you are going to get asked is "What is your CPAN ID?".

I simply cannot recommend it enough.

[dragonchild]

Good gods, this is the absolute perfect response to the OP's question.

$node->++ for 1 .. Inf;

Programming isn't about the language you use, it's about what you do with it. In Excel::Template, I just removed the usage of a feature in ExtUtils::MakeMaker because it was the source of 50% of my bug reports. Portability is hell, but Perl makes you face it.

Another is featuresets. PDF::Template has to depend on Unicode::String, but only if you're not Perl5.8+ - what's the best way to do that? It's not so easy ...