Learning Perl Objects, References & Modules 158
| Learning Perl Objects, References & Modules | |
| author | Randal L. Schwartz with Tom Phoenix |
| pages | 205 |
| publisher | O'Reilly |
| rating | 9.9 - Cannot find a fault |
| reviewer | Tony Williams |
| ISBN | 0596004788 |
| summary | Perfect book for taking your Perl skills to the next level |
Then for those that wanted a introduction to Perl and programming Randal L. Schwartz wrote Learning Perl, a book that has arguably become the definitive textbook for teaching Perl. The one weakness was that it left off before really getting to the guts of building large, complex projects in Perl. It did not cover classes, objects, breaking your code up into pieces or the more arcane aspects of variables, references. For this we had to resort to the last few chapters of the 'camel book' and I, for one, have never really been totally comfortable at this end of the language; when I'm reading someone else's code it might take a couple of reads to fully understand the process.
Now this weakness has been well and truly addressed. Schwartz, with Tom Phoenix, has written "Learning Perl Objects, References & Modules", a volume that takes the same steady approach to teaching you the more advanced topics as the earlier 'Learning Perl'. Schwartz has spent the years since writing 'Learning Perl' teaching and writing. You can tell, this is a superbly written book, not that 'Learning Perl' wasn't well written; it's just that this volume is far better.
The Guts
The book starts with a chapter on building larger programs that covers @INC, eval, do and require before discussing packages and scope. It then has several chapters on references that explains in well understandable fashion and increasing complexity all the ins and outs of references including dereferencing, nested references, references to subroutines and references to anonymous data before a final chapter on references that gives you some incredibly useful tricks such as sorting and recursively defining complex data.
The book continues with three chapters that give you a solid grounding in Perl objects. Here Schwartz has assumed that you know at least a little about object oriented programming, some may feel the need for more explanation of concepts might be required, but if you've had any experience in OOP before then the clear examples and descriptions here are probably all you want.
Modules are not as well covered, with only a single chapter, but it is hard to think of anything left out, it covers using them and building your own so well that it left me wondering what all the fuss was about, "seems obvious to me." The book concludes with chapters on building a distribution out of your module, testing it using make test (with Test::Harness), Test::Simple and Test::More before a chapter telling you how to contribute to CPAN.
Each chapter of the book concludes with a number of small exercises, designed to be done in just a few minutes, that cement the learning of the previous chapter. The answers to these are at the end of the book.
Conclusion
Once I'd finished I felt I had a much more solid grounding in Perl, certainly I was much better able to understand another programmer's code that dealt with such things as subroutine references and some complex data structures. While the subject matter of this book is almost entirely covered in 'Programming Perl' the tutorial aspects of this book made it much easier going. The style would be familiar to anyone who has read 'Learning Perl', light without being frivolous and extremely well written, Schwartz seems a master at reducing complexity to manageable bites.
This book is deceptively easy to follow, each new idea built onto earlier ones, each new language concept introduced in an easy manner. The writing is excellent, it's hard to explain why I appreciated it so much. That may be the reason, the writing isn't forced or heavy or too light or obvious. It just allows the solid material of the book to shine through. Go to the ubiquitous O'Reilly website and grab the example chapter (the site also has a few Errata, the Table of Contents and the code from the book) and give it a look.
I think this may well become a classic, I may well in ten years time talk of Schwartz's books with the same awe I now talk of Brian Kernighan's. I'll certainly eagerly await his next book and keep this one close until it comes. Oh, and Randal, how about 'Software Tools for Perl Programmers'?
You can purchase Learning Perl Objects, References & Modules from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This book - two thumbs down (Score:5, Insightful)
Which while some may enjoy cute little stories about the time the guy was up all night to meet a deadline, some of us read technical books to learn or enhance technical skills.
This is so far from K&R it's sacrelige to even make the comparison. Shame on you.
Try perldocs (Score:5, Insightful)
At some point you have to put the books down and start programming if you truly want to master the language. After the Camel book is probably a good time to start, with references to the Cookbook when needed. For other info, the perldocs are recommended.
Re:Readability.... (Score:5, Insightful)
For instance, in Java "String foo;" and in perl "$foo". Now, later in the code, if I see "$foo" in my perl code, I know immediatly that I'm dealing with a scalar, or %foo is a hash, whereas in most other languages I have to either remember the variable declarations or go back and find the variable declaration in the file.
Also, I think alot the supposed unreadability of perl has to do with regex. Since regex is such a basic part of perl, it gets used alot and when you come across "$_ =~ s/^([^ ]*) *([^ ]*)/$2 $1/;" you may attribute the mess of characters to perl when in fact, most of the mess is regex, which exists in many languages.
This is not to say that I haven't see lots of ugly code, perl or otherwise but I don't think perl is really any more difficult to read than other languages.
Perl without the Camels? (Score:3, Insightful)
Re:Try perldocs (Score:4, Insightful)
Having said that, the Camel book is probably the single most useful programming book I have ever read. I bought my copy 6 or so years ago (right after the 2nd edition came out) and I still use it to this day. It is unusual in that it not only allows one to pick up the language quickly and easily, but is concise enough to be used as a quick reference that is often more handy than the perldocs.
It may be that I had already been programming Perl for too long before the other books came out, but I was never able to find anything really useful at all from them.
Re:Readability.... (Score:5, Insightful)
The difficulty lies in the fact that it is possible to obfuscate Perl to such a degree, and that so many Perl hackers seem to think more obfuscation makes them look like a better programmer. There's even a contect that rewards this kind of thing.
If you want to write good, maintainable code, you can do it in Perl just as well as any other language. If you want to write an obfuscated mess, the same holds true. Sure, writing obfuscated Perl may make you feel more manly or whatever in the short term, but it won't help you keep your job when you can't read what you've written 6 months later.
Re:Perl is teh sux0r (Score:1, Insightful)
Why would they move to a less capable language?
(and I'm not even a Perl guy)
Re:What C programmers hold the K&R book in rev (Score:5, Insightful)
I couldn't disagree more. I learned C from the original K&R book. It was well organized, clear, and consise. The Camel book, on the other hand, often seemed like concepts on page n relied on concepts introduced on page n+1. I found that no matter how much I programmed in Perl (about a year's worth of time) and no matter how much I used the Camel book, I could never find what I was looking for without a massive search.
Half way through (Score:5, Insightful)
So, half way through, I give it two thumbs up. My Perl programming has just gotten a lot more sophisticated. Maybe I was dense to begin with but any step up is something I'm happy about.
As far as those nutty complaints about O'Reilly lingering at the bottom of this thread all I can say is that they've found their proper place.
Re:Readability.... (Score:2, Insightful)
But perl's mindset from what I can tell is power through brevity and flexibility. Going from it to Java is tortuous. So many words to type!!! But they both have their strengths. No doubt you're right that Perl code can be made readable if you make an effort. But I think readability has never been something that the Perl community has seemed to value, at least not as much as it should. So for anyone who's never learned it, it just seems needlessly and maybe purposefully obscure and hard to read. Making readable Perl has just never seemed cool to perl community from what I can see.
I don't say this as a criticism. I really like Perl and always have. But it may take a certain type of mind to love and master its brevity.