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.