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

Readability....

[fiftyfly]

Man I can't read my own perl, I can't imagine buying a book simply for the pleasure of reading someone else's

Re:Readability....

[pestilence4hr]

Actually, I disagree and think just the opposite. In many cases, I find that perl is easier to read because of all the "symbols" at the begining of variables and such.

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.

Re:Readability....

[eln]

The readability problem with Perl is a cultural one, not a language one. The language itself is very simple to read, with the possible exception of the more complex regular expressions.

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:Readability....

[Frymaster]

hey! there's some perl that's actually quite readable (and even poetic). witness the "black perl" script:

BEFOREHAND: close door, each window & exit; wait until time.
open spell book, study, read ( scan, select, tell us );
write it, print the hex while each watches, reverse its length, write again;
kill spiders, pop them, chop, split, kill them.
unlink arms, shift, wait & listen ( listening, wait ),
sort the flock ( then, warn the "goats" & kill the "sheep" );
kill them, dump qualms, shift moralities, values aside, each one; die sheep ! die to reverse the system you accept ( reject, respect );
next step, kill the next sacrifice, each sacrifice, wait, redo ritual until "all the spirits are pleased";
do it ( "as they say" ).
do it ( *everyone***must***participate***in***forbidden**s *e*x*). return last victim; package body;
exit crypt ( time, times & "half a time" ) & close it, select ( quickly ) & warn your next victim;
AFTERWARDS: tell nobody.
wait, wait until time;
wait until next year, next decade;
sleep, sleep, die yourself,
die at last
and it actually parses.

note: this script is for entertainment purposes only and is not meant as an endoresement of human sacrafise, real or virtual.

Re:Readability....

[pileated]

I think you're right about confusing obfuscation with programming machismo. But I have to say that no regular expression I've ever seen (except perhaps for last page of Mastering Regular Expressions) has been as baffling as something like $foo{$bar}{$foo2}. For me references and dereferencing and dereferencing shortcuts are the least readable elements of perl.

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.

It's the alpaca book

[M. Silver]

... for those of us who can never remember the titles, only the critters.

Re:It's the alpaca book

[smittyoneeach]

Possible /. poll:

Favorite animal not used on an O'Reilly cover.

My vote: tribble.

9.9?

[mopslik]

Rating: 9.9 - Cannot find a fault

Obviously, the review was calculated using an early Pentium.

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?

This book - two thumbs down

[stratjakt]

I cant disagree with the reviewer more. This book is crammed with anecdotes and stories, and very little actual information.

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.

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)?]

Try perldocs

[Ars-Fartsica]

So much of this stuff is in the perldocs. I applaud O'Reilly for supporting open source but outside of the Camel book and the Perl Cookbook, I think the rest of the books are mostly redundant.

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:Try perldocs

[eln]

The camel book is pretty much entirely in perldocs as well. In fact, most of it is verbatim.

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.

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" ?

[pileated]

How bout "has anyone started both books?" Based on that comparison I'd say I've gotten farther in this book than I ever did in Damian Conway's book (which I had really high expectations for based on reviews). In fact I think I started the Conway book more than once but never got more than 1/4 of the way through it. I'm halfway through this one now and have no doubts that I'll complete it.

Of course then I might go back and reread the Conway just to see if it makes more sense.

So for me I prefer this one. But that's just me. I liked the Conway book but it just got too dense too quick.

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

[afabbro]

I've read it cover to cover and use it frequently. Definitely the best perl book I've read (with the list of "perl books I've read" consisting of most of the O'Reilly line). Conway covers OOP theory, how to apply it in perl, neat perl-only tricks, and a lot of fun stuff. His examples are hilarious and his writing among the best traditions of technical instruction. Even OOP aside, I learned more about perl from Damian's book than anything else I've read. Highly recommended.

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.

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

[Thomas A. Anderson]

I started Damiens book, and it was way to dense for me. I just picked up Randals book and started it last night. It truly starts where learning perl (and the coookbook) ends and I feel that I'll be much more successdful understanding this book (and hence, becoming an OO perl programmer).

I'm not bagging on Damiens book at all - it just started above my head.

As for the poeple baggin on Randals book, my guess is is started at too low a level for them, so they think its useless - completly forgetting that they are just 1 of many perl programmers - all at different levels of ability.

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

[merlyn]

Damian's book is great, but a good comparison would be that Learning Perl is to the Camel what Learning Perl Objects, References and Modules is to Damian's book. Both of my tutorial books are tutorial in design, based on years of classroom experience in teaching these subjects. Both of the other books are reference in design.

Also, the OO part of the Alpaca book is only a portion of the text, and is necessarily light in coverage. The point of the Alpaca is to get you to understand most 100 to 10,000 line programs in as few moves as possible, just as the Llama is to get you to understand most 1 to 100 line programs. The design demands that I try to hit only the 80/20 point, covering the 20% of the features that are used in 80% of the programs. For the rest, you'll need to go to the Camel, the perldocs, and Damian's book.

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.

Perl without the Camels?

[RevMike]

One has to wonder if Perl would be nearly as popular if not for the excellent O'Reilly books to go with it.

I have it too

[JanneM]

I recently bought this, and for much the same reasons as the reviewer.

Basically, if your introduction to Perl was via "Learning Perl" then this is probably a great next step. I went through the Camel book and the Perl cookbook instead, and find that this one does not give all that much more information as I would have liked. This is not strange; the authors explicitly say in the preface that this is the companion book to "Learning Perl".

On the upside, it does give a good deal of useful snippets of info, and it manages to give clear explanations for some stuff that is otherwise quite opaque; the way it explains the Perl object model, for example is much clearer to me than the treatment given in the Camel book.

I would have given it 7.5-8 rather than the extreme score the reviewer gave.

Re:What C programmers hold the K&R book in rev

[murdocj]

That book is essentially worthless except for looking up random facts after you've been programming C for a few months.

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.

Re:What C programmers hold the K&R book in rev

[ggruschow]

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)?

Actually, this pretty much solved all my obscure or arcane C++ questions. In fact, while referring to that I haven't once had trouble figuring out if I was implicitly causing a conversion which caused a deep copy which in turn caused a memory leak since.

Of course, "Why did my program just pause for a 1/10th of a second, and how can I avoid that?" comes up more often now.

Half way through

[pileated]

and it's slow going, but I've sure learned a lot. Now maybe I'm dense but I don't think that references, anonymous hashes, references, subroutines are all that easily understood. In fact you can accomplish a whole hell of a lot in Perl without understanding them. But for anyone wanting to make the jump to larger more complex programs you really need to understand them. I'm just finishing the references section (first half) and still have the objects section ahead of me. I've read the tutorial on objects before and at first glance this book looks similar to it. But I didn't get as far in the tutorial as I would have liked, I think because I didn't understand references as well as I should. With the solid foundation that this book gives I think that I'll get a whole lot more out of the objects section, even if it more or less duplicates the tutorial (which I doubt).

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:Half way through

[jslag]

The way it makes you put different objects in different files/modules is so counter to Perl's scripting heritage

Different classes can be defined in the same file, no problem - just make a package declaration to begin each new one.

Having said that, I've never wanted to actually have more than one class in a file. Sure, OO is counter to 'Perl's scripting heritage', but so what? There's a reason that much of the good stuff on CPAN is written in an OO style.

Randal Schwartz (the writer)

[Bluetrust25]

Randal Schwartz is a regular over at PerlMonks.org. He's replied to a couple of my threads and helped me out of some sticky situations. It's rare for such a talented programmer to be so accessible and helpful to the public.

He's written well over 3,000 posts on Perl over at PerlMonks.org.

Randal will be at....

[TheMostBob]

Dragon*Con this year, and probably local hacker cons PhreakNIC and Interz0ne, if you want to meet him. He's a pretty happy drunk.

Bob

Re:OOP in Perl is a Bad Thing

[Christianfreak]

Wouldn't that be the fault of the people who didn't bother to learn basic concepts like OO programming rather than the fault of the people who know how to use it?

OO in Perl is not hard, sure its syntax is a bit different but the concepts are the same and there are multiple books (like this one), online resources such as this, and not to mention the existance of 4 (not 1 or 2 but 4) tutorials on OO in perl that come with the documentation. If people don't expect their "schmucks in the cube farm" to be skilled in a language then its no wonder that our jobs are going to India!