I find the most recommended book for learning and the most recommended book for reference; they are not always the same thing, and they are not always in book form.

I have, over the years, built a list of basic tasks I generally need to be able to accomplish in any home project. It starts with really basic tasks, like displaying output and performing computations; it moves on to doing arrays, processing command line parameters; it builds toward things like reformatting timestamps in various ways; and winds up with things like performing database operations, network interfacing, and graphics manipulations.

One by one, usually in the order listed, I proceed to write a program that does the thing, whatever "the thing" is. If I can, I try to learn how to write it as a library subroutine (the term in Perl lingo is "Module", BTW), and do that.

When I get through my checklist, not only have I done most of the things in the new language which experience has taught me I need to know how to do, I've written a library of routines to accomplish the tasks which either make it easier to do later (almost an interlingual abstraction layer, really), or at least provides sufficiently-documented examples of how to get it done.

For me, the Perl guide book was "Programming Perl", and the reference was the HTML perl reference guide that came with ActiveState Perl, more specifically the "perlfunc" entry.

Everything after that was experimentation. After a bit longer than I would have liked, my code started looking like it was written by a Perl programmer and not like a C programmer clawing his way through Perl.