Re: Seeking guidance on getting better at Perl.

Thanks for the good question; I've appreciated the answers as well. I have enjoyed doing much of what was mentioned above, such as going through the code/writing my own packages, and trying new things. In addition, here are my takes/recommendations on a few books:

Modern Perl (by chromatic) was the first one I picked up, but I found the structure of it a bit difficult for a newbie. I switched to Learning Perl and Beginning Perl to better effect. I especially recommend Beginning Perl.
Intermediate Perl and Programming Perl are next on my list. Programming Perl is supposed to be one of the classics, and bears Larry's name itself.
I haven't heard it mentioned much, but I am ABSOLUTELY impressed with "Mastering Algorithms with Perl," which is the equivalent of a data structures text book executed in Perl and has loads of hints that help to understand the guts of Perl (not to mention countless insights and code samples about referencing and doing all kinds of clandestine things with hashes, arrays, and references).

Finally, I wish I had sooner learned to start every program with:

use strict;
use warnings;
use diagnostics;
[download]

I'm sure you've seen the first two around everywhere; the last one supplements them with verbose warnings that give you full suggestions on what the problem might be, often including working suggestion examples. Not necessary for Perl pros, but if you are like me and can get lost in obscure meanings of the brackets, parenthesis, and commas, diagnostics is a life saver.

Comment on Re: Seeking guidance on getting better at Perl. Download Code

Replies are listed 'Best First'.
Re^2: Seeking guidance on getting better at Perl. by kcott (Archbishop) on Aug 18, 2013 at 05:57 UTC
While the diagnostics pragma is a useful tool for debugging, particularly when you are learning Perl, I would recommend removing, or commenting out, the `use diagnostics;` line in production code. Perhaps, as a general rule-of-thumb, consider doing this at the same time that you change `$DEBUG_MODE = 1;` [download] to `$DEBUG_MODE = 0;` [download] and for much the same reasons. -- Ken	[reply] [d/l] [select]
Re^3: Seeking guidance on getting better at Perl. by Endless (Beadle) on Aug 20, 2013 at 16:38 UTC
Absolutely. Nice point; I don't know what Diagnostics does to your code performance. For my learning time, what is $DEBUG_MODE best used for?	[reply]
Re^4: Seeking guidance on getting better at Perl. by kcott (Archbishop) on Aug 21, 2013 at 07:12 UTC
"I don't know what Diagnostics does to your code performance." If the messages are about problems that cause your program to abort, it obviously doesn't matter. For warning messages, you'd probably want to deal with them before code performance is an issue (i.e. prior to volume testing); so, again, it's unlikely to matter. You can always use Benchmark but, if you do, just be aware that generating a warning multiple times will only generate the verbose diagnostics message once. Furthermore, the time taken to get the message to your output device (I/O) is likely to far exceed the time taken to generate the message (CPU). All in all, testing `diagnostics`-related performance is not as straightforward as it might, at first glance, seem to be. "For my learning time, what is $DEBUG_MODE best used for?" I made up the `$DEBUG_MODE` variable merely to indicate whether or not the code was running in debug mode. Applications have their own ways of defining this, including: command-line options, configuration settings, variables. -- Ken	[reply] [d/l] [select]
Re^2: Seeking guidance on getting better at Perl. by pmu (Beadle) on Aug 18, 2013 at 15:36 UTC
Hi Endelss, Thanks for such a detailed answer. Aeterna Est Perspectum Cognitio	[reply]