These days I would never try to learn a language or write a program without a computer right in front of me. In my early days of computing I had no choice, but I would never go back.

But, if you must, then here's a tip from an old hand. Get a good (well recommended, preferably 'advanced' and if at all possible, relevant to your work or fields of interest), book with as much (good) code in it as you can. And at least one longish, complete example program--it doesn't matter what it does--and read the code.

Not the text, (and definitely not just the comments*), read the code.

*Personally I'd suggest trying to explicitly avoid reading the comments, until you're convinced in your own mind that you've understood the code to which they are attached. Then cross reference. (And don't be surprised if you cannot make your understanding of the code fit the authors comments! Even in the best text books, as you'll encounter in even the best maintained code by the very best programmers, the comments are never checked for accuracy.)

Scan the book and find that worked example, often at the back, and start there. Right on line one, and read it--out loud if your situation permits. Anything in that first line you do not understand, then turn to the index and look it up. Read the relevant passages until you do understand. But don't get bogged down in the detail. As soon as you're pretty convinced that you know what that line does move onto the next.

Read the variable names and try to understand why the author named them that way. Understand what type they are and make sure you understand why the author used that particular type for that particular variable. This is slightly less relevant with Perl than with statically typed languages, but understanding why the author use a hash rather than an array and vice versa will really pay off when you start writing your own programs.

Read the loops. Ignore what's inside of them at first, just make sure that you understand where they start and how they finish. If it's a C-style for loop for( my $i=ss; $i (<|<=|>|>=|other) $somevar; $i++ ) {..., make sure you understand the range of values that $i will run through. For while loops work out the terminating condition(s). Check inside the loop bodies for the presence of next & last and understand the conditions attached.

Don't skip lines because they look simple, or superficially similar to one you've seen earlier. Don't just read the line as a whole, but try to break it down into subclauses. Very relevant in Perl is to understand the context(s) involved in each clause and sub-expression. If the book is yours, and you're not prissy about your books, you could use a pencil to attempt to mark each part with a 'v','s' or 'l'.

When you encounter built-in functions (map, grep, open et el.), if the book lists perldoc-like detailed explanations of all the variations, don't try and understand them all. Just the usage in the line you are reading. Is it a 2-arg or 3-arg (or 1-arg) variant of open. Does it use a bareword or a lexical. What's the difference. What if any error handling is attached. When would it come into play.

Trying to read one, moderately complex program this way, in it's entirety, even if it is a program that you'll never have a use for, will stand you in very good stead. You'll learn not just how to read Perl code, but along the way, pick up a (hopefully reasonable) style of writing Perl code. You'll learn how to use the book as a reference. You'll pick up a good notion of what makes for good variable names (and probably some bad ones!). You'll get an idea of the myriad uses of hashes. And if the example's a good one, when not to use them.

The most valuable of these lessons (IMO) is learning to read the code. This is almost a lost art, and programming and programmers are the worse for it's relatively recent de-emphasis.

Oh! And enjoy! If it becomes tedious, go do something else for a while. Learning is always harder if you make a chore of it.

I wouldn't recommend to waste time by brute memorisation of stuff that you might never need. Rather skim through the Camel book, so you know where to find something to re-read in case you need it. You could spend more time on the parts that treat structure, concepts, and the non-technical side of perl (e.g. Perl-Culture). Any other interesting stuff will be memorised automatically.

Other Ideas: Higher level concepts can be studied without a computer. Although your computer will not be present, you'll have access to paper? The absence of a computer is a chance to exercise planning and to train conceptual work without being lured into the fiddle along until it works-mode. Maybe you can plan/design your next project and exercise these skills a little bit? Plan the things you'll do (train, program) when you get back to your computer.
E.g., learning some UML can be done nicely w/o a computer if that fits your plans. Patterns and OOP (P: Programming & Perl) are other potential candidates... or reading an SF-novel to recharge the creativity buffers ;-)

Yes, buy the Camel (which, as a fringe benefit, offers a good many insights into programming logic if one reads thoughtfully). And while you're at it, go also for "Regular Expressions Pocket Reference" (also O'Reilly), which will team up nicely with the regex intro in "Learning Perl."

Re "programming logic:" Newcomers here are often advised to sketch out the steps to a solution to their then-current puzzles with pencil, paper and ordinary language. Doing so may be more useful to you than any book you can swallow in a week. So, perhaps you'd do well to divide your week between reading the Camel and writing plain-English (or your own preferred tongue), step-by-step synopses of some problems that intrigue you. (This assumes that in the course of your "few months" "studying Perl" you've come to some understanding of the concepts behind if (...) {...}, for, while and the like.

Update, 20081114: Fixed spelling of "fringe." Duh!

{beginning,learning,intermediate,programming,mastering,advanced} perl are all worth a look

They have exercises, so you can keep yourself entertained on aircraft and the like.

You could pick up a discount laptop off a popular online auction site, and take it with you ... you never know when you'll want to read perldocs

I highly recommend buying the Camel. I don't like it much as a reference work, it's too hard to find stuff. But for a bedtime read instead of the SF it's great!

I've always found writing out code on paper and then "running" it in my head to be helpful. Once you get back to your computer you can even test if the outputs you produced are correct by running the code in perl and see if the results match up.

I found the "Perl Cookbook" helpful. I wouldn't try to memorize so much, but instead jot down short notes about thinks you found interesting (or mark them in the book with "post-it" notes and a marker pen). If you have an organizer, you might key in the notes and later transfer it to the computer.

Actually, I end up writing interesting notes about programming on shared space on the web, so that I can access it whenever I have internet connection. This doesn't work for you while you are offline, but you may transfer the notes later to some place on the net. Having it online is much better than having handwritten notes....

Cheers,
Darren :)

I can tell you that Larry Wall's (Programming Perl) is an excellent book: fun, interesting, and educational. Just read and enjoy it. You'll likely learn a great deal without even trying.


sas

Some of my best work has started out on napkins or the backs of envelopes. I've worked out API issues and outlined the Synopsis of the perldoc for my next project while riding a bus or sitting on a beach. One of the more useful scripts I wrote at at an earlier job five or six years ago started as a discussion with a friend who teaches CS at UGa. I outlined a file format on a napkin and picked his brain about parsing it with Perl and marking it up with LaTeX.

When I made the choice to learn programming as a craft, instead of merely dabbling enough in it to simply get my work done, I borrowed a friend's O'Reilly's Library and consumed it one lunch break at a time over several months. It was a pleasant distraction from my other responsibilities on that job.

The recommendation above to review some working code is an excellent one. Pick some popular or esoteric module from the repository, print it out (check out a2ps for this) and study it. Code reviews are an important tool (recommended by Code Complete, among, I'm sure others). And is frequently a final review for me before committing my latest work to CPAN or even to my svn repository.

-- Hugh

Can you use another computer? neighbor, girlfriend, business computer?

If you can, you should be read cpan modules source and/or tests, you can learn a lot...

the source its more easy because you dont need to download the tar.gz, you can access directly http://search.cpan.org/src/PETDANCE/WWW-Mechanize-1.50/lib/WWW/Mechanize.pm and print :)

Good Luck!

I'm assuming you're on vacation and have a computer at home. If not- I have a ibm 600e with bad battery that's running fc4 perfectly. You can borrow it for the cost of shipping.

You can get a laptop like this off ebay for $60- likely with win95. Might be a pain to jack in linux without cd. I used network.

I think a more useful study away from a computer would be something like The Mythical Man Month or Hackers and Painters- This kind of stuff is incredibly valuable information- and you won't need a computer.