Learning Perl Objects, References & Modules

honestpuck writes "In the world of Perl there was once only the 'camel book,' held in perhaps as much reverence as 'K & R' among C programmers. It certainly appealed to roughly the same audience, those who wanted a short, sharp introduction to a programming language. It was with a problem that needed solving and a copy of the camel book that I started as a Perl programmer." Read on for honestpuck's review of another book he regards at least as highly. 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.

Comments

me too

[514x0r]

It was with a problem that needed solving and a copy of the camel book that I started as a Perl programmer

how else would one want to learn perl?

What C programmers hold the K&R book in revere

[squarooticus]

That book is essentially worthless except for looking up random facts after you've been programming C for a few months. In contrast, the camel book is useful even for long-time Perl hackers, because Perl has more built into the language (e.g., regexps, hashes, etc.) than C, the latter of which is incredibly simple by comparison.

[Aside: The book I use most often is Stroustrup's C++ Second Edition, which in itself is rather vague and outdated wrt the details I need to know most often these days. I'm thinking of getting myself a copy of one of the C++ specs to help me answer the really obscure questions. Does someone recommend a particular spec (e.g., ANSI, ISO)?]

Damien Conway's "Object Oriented Perl" ?

[bongoras]

Has anyone read both this book and Damien Conway's book? I'd be interested in a comparison. I like the Conway book, but it's a little dense for me. Or I'm too dense for it... either way...

Re:Damien Conway's "Object Oriented Perl" ?

[bunco]

Conway's book is the best I've read on the subject of perl OOP. If you take the time to make sure you *understand* each and every concept and mechanism, the book will leave you with a firm understanding of objects. This shouldn't be a problem as the book is a delightful read. A firm understanding of the perl language, references, globs, packages, etc would be an important requisite as the book is not for the novice.

Rating

[Karamchand]

Rating: 9.9 - Cannot find a fault. Uhm. Now please tell me - why not 10 then?

books

[erikdotla]

Some people need books, others don't. Personally I find the ActivePerl documentation to be excellent.

The idea that you can do a PPM search for a module via CPAN based on your need, download it, and have it's docs integrated into the centralized documentation is great. perlfunc, perlre, perlobj, etc are a bit arcane but with a little elbow grease and a good editor (SlickEdit!), you figure things out pretty quick.

Re:books

[erikdotla]

Heh, I was kidding on the demote but who cares.

I think the books vs no-books is based in part on age, but only because age relates to school, which is book oriented. Those who have been out of school a while, or never went to college, may find through experience that skipping books and going straight for built-in docs (or trial and error) works for them.

Younger folks tend to prefer books especially if they just finished, or are still in, college, for obvious reasons.

I see the Youthful Bravado angle, and that's certainly present, but I think it's much more common in older folks. All the interns at my company that we snatch from the nearby college always have a pile of programming books. All the older folk have bookshelves with 20 year old C books that they claim are all they need, and are covered in dust.

Forget the pros and cons, that's trollbait. I think what you're really wondering is why people switch off books, or are turned off by books in the first place, as a tool for learning new things. I think the same people who skip tech books as a learning tool also don't read much other stuff (examining myself.) They just don't like books.

I also believe that the smarter and more experienced you get, the more of an obstacle books are for learning something new, quickly. When any of us learn something new, we pick up a certain amount through intuition, experience, and at some point hit a wall and have to get help. If you're the type that hits the wall much later, you're less likely to hit a book since it wants you to start at the beginning. Documentation (especially online) tends to be better organized so you can find your own entry point into the docs and continue where you feel you left off.

However, I think once you've gotten really good at something, you should pick up a book. Start at the beginning, but you can go fast through the parts you know. You'll pick up all kinds of stuff you may have never otherwise seen.

I used Perl for about 2 years before I wrote a single regular expression. I saw some intriguing stuff in a book, but hated the book, so I fired up perlre and it changed my world.

Nice chatting with you pileated.

OOP in Perl is a Bad Thing

[Le Marteau]

... because very few perl scripters know how to do it... write an OOP script in Perl, and only an expert will be able to maintain your work.

This is so common in Perl (and other languages). Especially with contractors, for some reason. They come in, write expert level code, using all the secret codes and handshakes, then the average schmucks in the cube farms cannot maintain the code.