I have been dabbling in Perl on and off since about 1993. For a decade or so, it was mostly "off", and then I took a position programming Perl full time about a year ago. We currently use perl 5.8.9, and I spend part of my time teaching Perl to old school mainframe COBOL programmers. Dare I say, I am the target market for this book?
The author takes the time, to explain that you should ever use `PERL', since it's not an acronym. I find it funny that the section headings utilize an "all caps" font, so the author does end up using `PERL'. That's not even a quibble, I just chuckle at such things.
The author covers the perlbrew utility. Fantastic! What about all of us schmucks that are stuck with Windows at work, or elsewhere? Throw us a bone!! Ok, I don't think there is a bone to throw us, but the author does a great job of covering the options for Windows.
He covers the community! Amazing! Wonderful! Of all things a beginner should know, this is one of them, and it's great that the author has taken some time to describe what's out there.
One other note are the...notes. I love the fact that the author has left little breadcrumbs in the book (each starts with "NOTE" in a grey box), warning you about things that could ultimately hurt you. Case in point, the warning on page 13 regarding the old OO docs that came with 5.8 and 5.10. Wonderful.
An entire chapter on CPAN? Yes!!! CPAN is a great resource, and part of what makes Perl so great. The author even has some advice regarding how to evaluate a module. Odd, though, there is no mention of the wonderful http://metacpan.org site. That is quickly becoming the favorite of a lot of people.
It is great that the author covers the various cpan clients. However, if you end up in a shop like mine, that ends up being useless as you have to beg some sysadmin for every module you want installed.
The basics of Perl are covered here in a very thorough way. The author takes you from "What is programming?" to package variables and some of the Perl built-in variables in short order.
Much more useful stuff is contained in this chapter. I mean I wish pack() and unpack() were made known to me when I first saw Perl, but hey, Perl is huge and I can understand leaving such things out, but I'm happy the author left a lot of them in.
Herein lies another one of those wonderful grey boxes. On page 106 you'll find the box labeled `What is "TRUTH"?' So many seem to stumble over this, so it is great that it's in the book and your attention is drawn to it.
Here you'll find the usual assortment of control-flow discussion including the experimental given/when, which most will know as a "switch" or "case" statement. The author even has a section to warn you against your temptation to use the "Switch" module. That's good stuff.
Wow references so early in the book!?!? Upon reflecting a bit, I think this is a good move. They allow so much flexibility with Perl, that I'm happy the author has explored them so early.
I do find it odd that a chapter on subroutines comes after a chapter on references, though. It seems like subroutines are the obvious choice to get a beginning programmer to start organizing their code. Hence, it should have come earlier.
Having said that, I love the authors technique of "Named Arguments" and calling the hash passed in "%arg_for". It reads so well! I'm a fan and now tend to use this. Of course, it is obvious now that references needed to be discussed first, or this technique would just be "black magic" to a new Perl person.
There are so many other good things in this chapter: Carp, Try::Tiny, wantarray, Closures, recursion, etc. This is definitely a good chapter to read a couple of times and experiment with the code.
As the author points out, an entire book has been written on the topic of regular expressions (perhaps even more than one book). The author does a good job of pulling out the stuff you're most likely to use and run across in code.
Here's one that sort of depends on what you do. It's good to know, but if you spend your days writing web apps that never interact with the file system, you'll never use this stuff. Of course thinking that will mean that you'll use it tomorrow, so read the chapter today anyway. :)
A chapter on just sort, map, and grep? Yes, yes there is, and it is well worth reading. This kind of stuff is usually left for some sort of "intermediate" level book, but it's good to read about it now and try to use them to see how they can help.
Ah, yes, a good chapter for when you've gotten past a single file with 100 subroutines and want to organize that in a more manageable way. I find it a bit odd that POD comes up in this chapter, rather than somewhere else. I guess it makes sense here, but would you really not document until you got to this point? Perhaps, but hey, at least you're documenting now. :)
Chapter 12 and 13
I like the author's presentation of OO. I think you get a good feel for the "old school" version that you are likely to see in old code bases with a good comparison of how that can be easier by using Moose. These two chapters are worth reading a few times and playing with some code.
Unit testing for the win! I loved seeing this chapter. I walked into a shop with zero unit tests and have started the effort. Testing has been part of the Perl culture since the beginning. Embrace it. We can't live in a world without unit tests. I've been doing that and it hurts, don't do that to yourself.
"The Interwebs", really? I don't know what I would have called this chapter, but I'm happy it exists. Plack is covered, yay!!! Actually, this is a good overview of "web programming", and just "how the web works". Good stuff.
A chapter on DBI? Yes! This is useful. If you work in almost any shop, data will be in a database and you'll need to get to it.
"Plays well with others"...hmmm....another odd title, yet I can't think of a more appropriate one. How about "The chapter about STDIN, STDOUT, and STDERR". That's pretty catchy, right?
A chapter on common tasks, yet I've only had to do one of those things ( parsing and manipulating dates). I think my shop is weird, or I just haven't gotten involved with projects that required any of the other activities, such as reading/writing XML.
Including the debugger and a profiler is good. However, how do you use the debugger with a web app? I don't know. Perhaps one day I'll figure it out. That's a section I wish was in the book. The author doesn't mention modulinos, but I think that's the way to use the debugger for stepping through module. I could be wrong. In any case, a little more on debugger scenarios would have been helpful. A lot of those comments also apply to profiling. I hope I just missed that stuff in this chapter. :)
Wow, the sort of "leftover" chapter, yet still useful. It is good to know about ORMs for instance, even if you are like me and can't use them at work (yet).
Quick coverage of templates and web frameworks? Yes, and Yes! I love a book that doesn't mention CGI.pm, since it is defunct now. Having said that, there are probably tons of shops that use it (like mine) until their employees demand that it be deleted from systems without remorse. So, it probably should have been given at least some lip service.
I am an admitted "fanboy" of Ovid. Given that, I can see how you might think I got paid for this or something. I didn't. I just think that he did a great job covering Perl with this book. He gives you stuff here that other authors have separated into multiple books. So much, in fact, that you won't even miss the discussion of what was improved with Perl's past v5.10.
All in all, if you buy this book, I think you'll be quite happy with it.