Please let me know what I should learn in Perl, besides the fundamentals in Learning Perl and Perl Cookbook.

You should learn to solve your problems in perl, and the problems of those who are willing to pay you for doing so.

What exactly that is greatly depends on you, your environment, you possible employers and so on.

Maybe just look at the jobs listed at http://jobs.perl.org/ to get a feeling for what employers want.

Dear anonymous letter writer,

Biz happens all over the place, so you better learn both Perl and algorithms really well. Compute centres, bioinformatics, banking, insurance and web hosting might not really overlap, but together should cover pretty much all of computer science, all of the major platforms and just about all kinds of uses, including the absurd and the patently impossible.

Now if you'd restrict yourself to a more specific professional field, maybe you can strike out some areas and delay learning some of the more obscure skills and fields.

Sincerely,
your most-loved journal's favorite columnist

Please let me know what I should learn in Perl, besides the fundamentals in Learning Perl and Perl Cookbook.

To make some bullet-points about "what to learn" I would start with this list:

• Also read (cover to cover) Programming Perl - it is the definitive guide to the language itself.
• REGULAR EXPRESSIONS!!!
• Learn how to install CPAN modules
• Learn how to write CPAN modules
• Unit Testing
  • Test::More is a great place to start.
  • Devel::Cover should be looked into from there.
  • Devel::NYTProf might come up next.
• object-oriented design
  • encapsulation
  • polymorphism
  • inheritance
  • abstraction
• Linux - the basics
  • ls
  • ps
  • top
  • grep
  • find
• Database programming and design
  • SQL
  • 3rd normalized form
• Network Programming Basics
  • difference between TCP and UDP
  • difference between a socket and a filehandle
• multi-threaded programming
  • difference between processes and threads
  • know when to use threads vs forks
  • understand how to distribute workload in a way that gets the job done as quickly as possible
• event-based programming
  • callbacks
  • events
  • publish/subscribe pattern (aka the "observer" pattern)

It would also be worth familiarizing yourself with what are known as "Design Patterns" since knowing them will help you articulate (in code) what you are trying to accomplish.

Agreed with most of this list. Two remarks:

I don't think perl's threading is all that interesting (except when interfacing with threaded C/C++ code).

Multi-process (forking/IPC) code is more useful just because it's more general (and also easier to translate into multi-machine/networked code), and because of that I'd recommend POE as a good framework to lean since it really makes IPC, networking and event programming a lot easier.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

A more philosophical answer pointing out a suitable learner's mindset in approaching Perl as a new language/skill:

(combining three themes from the camelbook)

Hubris is a valuable virtue in a beginning Perl programmer, as it allows him to cover the easy 90% of a complex problem while just applying newly learned Perl baby talk.

(badly mangling another camelbook theme)

Having taken care of the easy portion with easy baby talk, Perl still makes solving the hard 10% possible with adult object orientation and modularization.

(with baby talk and adult oo just being two extreme examples for TIMTOWTDI, in other words, both are valid and valuable perl styles. While this encourages the make-your-hands-dirty-with-code virtue, it's still pretty much the opposite of the time-is-money blinders approach of the base node)