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.

Re:Readability....

[samf]

Oh no, I'm going to get moderated down, but honestly, I don't mean this as a troll.

This got posted to a thread I was following once:

/*
* S_intuit_method
*
* Does all the checking to disambiguate
* foo bar
* between foo(bar) and bar->foo. Returns 0 if not a method, otherwise
* FUNCMETH (bar->foo(args)) or METHOD (bar->foo args).
*
* First argument is the stuff after the first token, e.g. "bar".
*
* Not a method if bar is a filehandle.
* Not a method if foo is a subroutine prototyped to take a filehandle.
* Not a method if it's really "Foo $bar"
* Method if it's "foo $bar"
* Not a method if it's really "print foo $bar"
* Method if it's really "foo package::" (interpreted as package->foo)
* Not a method if bar is known to be a subroutne ("sub bar; foo bar")
* Not a method if bar is a filehandle or package, but is quoted with
* =>
*/

Without being too negative, I would say that this is an example of a core language feature that makes for difficult-to-understand code. I imagine that there are more examples like this.

Would you agree, or would you argue against this?

Re:Readability....

[Anonymous Coward]

If you can't read you own Perl code then you need to change your habits! Now!

Re:Readability....

[JamieF]

>Now, later in the code, if I see "$foo" in my perl code,
>I know immediatly that I'm dealing with a scalar

And this could be any one of:
- an integer
- a real number
- a string
- a reference to an array
- a reference to a blessed array
- a reference to a hash
- a reference to a blessed hash
- a reference to a scalar
- a reference to a blessed scalar

Well thank goodness that $ is there so that it's so easy to tell what type of data the variable holds.

I disagree that regex's are the reason some Perl code is hard to read. I think that when folks contort their code so as to minimize the number of bytes of source code by [a] failing to comment their code [b] failing to use descriptive variable names and [c] using all sorts of magic Perl variables like $_ and $ and $& and $@$%@#$^$&, that's when it gets hard to read. Who the heck knows what all of those stinkin' magic variables do? You have to have the camel handy in order to decipher that.

Re:Readability....

[JamieF]

I think you're forgetting about all of the built-in $ variables.

NOTE: I had actually written out a list of them here, and there are about 30 of them, but /. won't let me post it:
"Lameness filter encountered. Post aborted!
Reason: Please use fewer 'junk' characters."
Which kinda makes my point in a roundabout way.

I mean, seriously. These are all valid variables in Perl and have specific meanings. But they aren't exactly readable. Some of them (like $| and $_) you probably already know, but the Perl brevity / look-me-so-clever culture leans towards doing more with less code, and maintainability be damned.

Re:Readability....

[z00z]

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.

I totally agree with you. Even in the case of regexps, the /x modifier is available and you can use it to add spaces and even comments to enhance your code's readability. So again, it boils down to the programmer and his/her preferred style.

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.

It IS quite easy to obfuscate Perl code, but I disagree that Perl hackers like to obfuscate more than others. Just lurk around comp.lang.perl.misc for a while and see the quality of code over there. You are bound to get crappy code in any language, but crappy code comes from crappy programmers.

There's even a contect that rewards this kind of thing.

As for the contest(sic) you mentioned, I'm not aware of any such contests. The only thing that I know of is the Perl Golf contest, and I have participated in all of the official ones, and I can tell you that I learnt much more about Perl there than in the last 5 years that I've been hacking Perl. The idea is not to obfuscate, but rather to shorten the code as much as possible to solve a given problem.

For real obfuscation, check out Damian Conway's Acme::Bleach module and Andrew Savige's Acme::EyeDrops module, both availabe from CPAN.

Re:Readability....

[Anonymous Coward]

That is certainly true for many of the special variables (probably most of them). However, any Perl programmer should know at least what $_ is, as it is used so often.

Re:Readability....

[merlyn]

That code is handling "indirect object" syntax, a syntax that was an interesting experiment but is all but extinct, after discovering that it can lead to some interesting problems. Unfortunately, for backward compatibility, that code still has to DWIM a bit to keep the legacy code working.

Re:Readability....

[Anonymous Coward]

A pointer to perlvar is probably useful.

The thing is, the average Perl program doesn't even use most of these. $_ is the most common (and its very purpose is why it's such a short name). $! and $@ for errors (but for some reason most of those who complain about perl's cryptic syntax are also those who skip error checking). @_, for argument passing.

And those 4 will get you through most of Perl except for a few odd bits. Any others are either one shot uses (which you probably should've written a comment for), or are just things you can let people look up.

One of the great things about perl is the thoroughness of the supplied docs. Such a shame most linux distros package them up in a separate perl-doc package that is rarely installed by default. It's also a shame that many of the (non-ORA) Perl basics books neither cover perldoc or even cover POD.

Re:Readability....

[wideBlueSkies]

Myself, I write Perl code to look as much like C as possible.

Then if there's something Perl-like that's more efficient, or that can't be done with C-like syntax, I comment it up.

So it IS possible to write readable Perl. You just have to think about doing it WHILE you're coding.

wbs.

Re:Readability....

[CoolCat]

Naming your variables is the clue here... I cannot event think of some code where I create a variable called foo.. name it afther its type, eg. sFoo for string, nFoo for int etc.. much more pleasing to read code. Same thing with classes and objects, classes = cFoo, objFoo for objects.. you get the clue.

Re:Readability....

[japhmi]

There's even a contect that rewards this kind of thing.

As for the contest(sic) you mentioned, I'm not aware of any such contests.

Really, it's quite famous. Check out the results for the last several at The Perl Journal.

Re:Readability....

[Koschei]

Um. No. Name for its purpose, not its type.

Array containing a bunch of squares? @squares.

blah. I'd cite more examples but variable names and example code don't tend to come to me while not writing actual code.

Hungarian is just so much waffle. The main reason I enjoy having sigils in front of variables in Perl is that I can't clash with reserved words. I don't care so much about using it to differentiate between scalar, array and hash. Heck, in Perl 6 much of the distinction between an array and an arrayref will be gone (in most cases they'll be usable interchangeably) so the sigils will matter even less.

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

[Anonymous Coward]

Ya great! Now I'll just get it confused with the llama book....

Re:It's the alpaca book

[smittyoneeach]

Possible /. poll:

Favorite animal not used on an O'Reilly cover.

My vote: tribble.

33% cheaper at amazon

[Anonymous Coward]

$3.50 cheaper at amazon (extra 10% off = 33% cheaper)

9.9?

[mopslik]

Rating: 9.9 - Cannot find a fault

Obviously, the review was calculated using an early Pentium.

Re:9.9?

[Anonymous Coward]

Why are these lame jokes becoming popular again?
In capitalist Slashdot, early Pentium calculates YOU!

Re:9.9?

[mopslik]

Why are these lame jokes becoming popular again? In capitalist Slashdot, early Pentium calculates YOU!

(stares blank-faced at equally lame Yakov imitation)
It's like the square root of a million -- some things we'll just never know.

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?

Re:me too

[joeykiller]

I seriously believe being a perl programmer is a little like being a smoker: After smoking a while you don't remember why you started anymore. All you know is that it's easier to continue than to break the habit. That's the case for me, anyway.

Re:me too

[hondo77]

Me in 1999: I have to leave this stinking job! Hmm, dot-coms sound interesting...

well!

[Anonymous Coward]

how about putting a spoiler warning! you practically gave away the ending!

You did the author a huge disservice.

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.

Re:This book - two thumbs down

[jdbo]

I haven't read this book, but I'm fascinated by the moderation of the parent comment as "insightful"..."informative", perhaps... after all, it does confirm that the light nature of the writing style will turn off those who prefer dense technical writing... but it does so in a shallow manner that sheds no light on why such a writing style might be a bad thing. If anything, this post represents the opposite of insightful thinking.

Re:This book - two thumbs down

[Anonymous Coward]

+4 insightful? Stratjakt is a known troll. Check out his other work.

Re:This book - two thumbs down

[gantrep]

see, I was right

You dont have to read the book, or even know what it's about. Look for a post I made in this thread that got +5 Insightful. I've never read this book and I dont use Perl. Just string together a bunch of "kudos" or "boos" and toss in a couple buzzwords (K&R works fine), and there you go.

Re:This book - two thumbs down

[stratjakt]

You're a superhero. You keep track of "known trolls".

Just because I think that you and the rest of your groupthink idiot ilk are laughable and worthy of ridicule, doesn't mean that you need discount everything I say.

You're like a second grader with his hands over his ears screaming "LALALALAL I CANT HEAR YOU".

Go fuck yourself, put me on your foes list, and dont bother reading my posts.

Thank you for your (no doubt worthless) time.

Re:This book - two thumbs down

[Eric Ass Raymond]

And that makes his opinion irrelevant just how? I assume your comment implies that the post above should have been moderated down instead of up. Why? Because of his posting history?

"Stratjakt is a known Communist. Check out his other work."

You are suffering from the Dubyaitis: everything's black and white, good and evil, trolling and "serious" slashdot use. The world doesn't work like that, my friend. The world is not black and white. The world is shades of gray.

Re:This book - two thumbs down

[Anonymous Coward]

He's the second grader?

Ha!

Re:This book - two thumbs down

[pongo000]

And while we're at it, let's make perfectly clear that Learning Perl is simply an abridged version of Programming Perl.

Mr. Schwartz does seem to know how to milk those cash camels, though!

Re:This book - two thumbs down

[Anonymous Coward]

He either read the book and is being truthful, or didn't read it and is full of shit. I fail to see how this is anything but black or white.

Re:This book - two thumbs down

[Eric Ass Raymond]

either read the book... or didn't read

Black and white.

Re:This book - two thumbs down

[pileated]

Umm, what pages were those anecdotes and stories on????
Still haven't found one at page 76.

You did read the book didn't you?????

Re:This book - two thumbs down

[Our Man In Redmond]

This is so far from K&R it's sacrelige to even make the comparison. Shame on you.

Um, the reviewer was comparing K&R to "Programming Perl" -- a/k/a "The Camel Book" -- not to the book being reviewed. Which is a fair comparison in that both books pretty much define the language in question.

Re:This book - two thumbs down

[davorg]

And while we're at it, let's make perfectly clear that Learning Perl is simply an abridged version of Programming Perl.

Er... no. Learning Perl is a tutorial, Programming Perl is a reference. There's a huge difference.

Re:This book - two thumbs down

[pongo000]

Large quantities of material, much of it verbatim, was lifted from the PP book for the LP book. There's very little in the way of added value in the LP book, just some reorganization.

Re:This book - two thumbs down

[merlyn]

Large quantities of material, much of it verbatim, was lifted from the PP book for the LP book. There's very little in the way of added value in the LP book, just some reorganization.

As the original author of both PP and LP, I can certify that this is patently not true, and borders on libel.

Are you prepared to show evidence?

Re:This book - two thumbs down

[pongo000]

Everything that is covered in LP is covered in PP. So what's your point?

Re:This book - two thumbs down

[merlyn]

"covered" is not "lifted... verbatim". If you can't tell the difference between tutorials and reference material, you're not qualified to make the comment you've made. You still haven't shown any part of PP that was "lifted" to make LP. Put up or shut up.

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

Recommend Perl: The Complete Reference

[neptune1]

Perl: The Complete Reference is a very good and easy to read and understand perl book. Its somewhat old but still a great book.

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.

Re:Try perldocs

[althalus]

I can't say I fully agree with that. While the book may seem redundant for the experienced perl programmer, I just finished it and would definately say it fits it's target market. I know a bunch of developers who started with the llama, went to the camel, but lost out on the good info that this puts inbetween. Some kinda Oreo Cream filling between the llama and camel.

I would definately recommend this book to the developers who are at that stage of their development. It's a useful tutorial style book for those who are learning. It doesn't pretend to be a reference, or do things it shouldn't. It does it's job, and does it well.

I'm just mad that this was posted, since I was going to submit my review this week.

Re:Try perldocs

[Anonymous Coward]

The book is far better than the relevant perldocs when it comes to _learning_. For reference, the perldocs are great, but for learning? No. Not even the tutorial ones.

On the other hand, there's this book (the alpaca) and the llama. Together, they get you from knowing nothing about perl, to being able to write your own modules/classes and releasing them on CPAN with tests.

If you need _more_ information than the books give you, or want to know precise details on the perl you're using, or you want a _reference_, then perldoc.

Anyway, I can only assume you haven't read most of the other Perl books out there (but with over 100 of them, not counting just ORA, that's probably not too surprising). Many of them either extend the perldocs, or they present friendlier text.

There are quite a few duds, but there are also quite a few excellent books.

Re:Try perldocs

[wideBlueSkies]

Yeah, the perldocs are great. And yeah the Camel is a rehash of the perldocs. But it's nice to have a dead tree on the desk to stick bookmarks and postits in the pages, and to highlight.

I know that I'm stating the obvious, but nothing in electronic media comes close to replacing printed manuals.

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.

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

[mysticgoat]

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.

Hi, Randal,

The Gecko book was very important to me when I made the big step from Perl as a replacement for awk scripts to Perl as an application development tool, around 1997 (the world around me has dictated that I work in Windows, hence gecko). I've still got my copy within reach from the keyboard and it's one of the more tattered and used books in my collection. Thank you very much! You've been a big help in my career.

I learned more advanced techniques from Srinivasan's Black Jaguar, aka Advanced Perl Programming. The first few times I went through it, it was not an easy read, but that may have been my problem in getting my mind around the concepts. I use it and Conway's OOPerl book as references now.

How would you compare Learning Perl Objects, References and Modules to the Black Jag? I'm certain to buy the book when finances allow-- I have nearly a complete set of O'Reilly Perl books... it's like collecting cook books...

--
Will Woodhull
aka mysticgoat (mostly for historical reasons)

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

[szap]

I second most of the positive comments here about Damian Conway's book.

Just want to add that even after using perl for a few years, his beginning 1/3 chapters alone are worth the price of the book. It's a refresher on the fundamentals of perl, with good, funny examples of just about 90% of everything I knew. Even lots that I *didn't* know, with me going "Wow, I didn't know you can do that!". Heck, most of the important stuff from the Camel book is summarised here.

The last 2/3 that deals with OOP is just gravy. Yes, these parts are dense, but you

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

[merlyn]

The Jaguar book is dated. It filled a nice niche at the time, but the world progressed beyond it rather quickly. It describes a deprecated XS interface, an obsolete module packaging scheme, and objects before we really understood everything that was going on in Larry's head.

It's still selling because it still sells. O'Reilly doesn't drop books that still make a profit, even when they're outdated.

I'd consider the Alpaca plus Damian's book to be a complete replacement of everything that the Jaguar had attempted to cover, and the Alpaca presents the material in a tutorial fashion, something the Jaguar lacked.

O'Reilly website truly ubiquitous?

[Feynt]

If it is so ubiquitous, why embed a link to it?

Rating

[Karamchand]

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

Re:Rating

[vasqzr]

The next edition will be a 10. Or a 9.5

Sounds like my employee review.

"I'm only giving you an 85%. This way, I can give you an 88% next year, and since you're 'improving' you get a raise."

If at first you give something 100%, any other than 100% is BAD.

Re:Rating

[UserGoogol]

Some people feel awkward rating anything 10 ever because (if taken incredibly literally) it means that there is no book which can ever be better than this book.

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

[Anonymous Coward]

Dietel and Dietel is good.
C++ How to Program.

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]

Cmon, this wasn't interesting. Maybe a 1. I demand that my points be revoked immediately.

Re:books

[pileated]

I'd be happy to knock it down to a 2 or so.:-)

BUTTTTTTTTTTTTTTTTTTTTTTTTTT, just before I read your post demanding that it be knocked down I was thinking that someone should start a new subject on "Learning programming through books - pros and cons" or some such thing. I keep noticing these statements from people who claim that they don't need to read books, and seem to be proud of it. Personally I think that's nuts. But there certainly do seem to be a number of people of that persuasion. Much of it seems like some sort of youthful bravado but I wonder if there's also some truth to it.
I guess I'm wondering if there is a change and that there is a growing number of accomplished programmers who really don't read books. I'm happy not to be one of them but I still find it an interesting question. So, for prompting this totally unrelated post, I unofficially demote your first post to 2.0.

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.

Re:books

[ReadParse]

I think there's more to books than "need". I don't need technical books in most cases, because of the extensive information available online. This is especially true of perl, whose documentation is unbelievably vast. But I *like* books (as opposed to need). They're nice to have on the shelf and in a comfortable chair. It gets me the heck of the computer from time to time to read some thoughtful insight from somebody more experienced than me, and to read text that didn't have to be antialiased :)

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.

Re:Perl without the Camels?

[larry bagina]

And I wonder if O'Reilly would be so successful without the perl books.

HOORAY!!

[freeze128]

Finally! *NOT* reading the article pays off!

My advice

[Anonymous Coward]

Wait for the movie.

I heard O'Reilly got Tom Cruise to be in 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:Recommend Perl: The Complete Reference

[dlosey]

I agree!

Once you've read the camel book, you are truly "over the hump", and can really start to program in Perl.

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

[Anonymous Coward]

Don't buy it. It's a cheap Chinese knock-off of Deitel and Deitel, whom I wholeheartedly recommend.

Re:Perl is teh sux0r

[Anonymous Coward]

Perl died in the 90's when PHP was introduced... if you code perl, then get w/it and code PHP

Why would they move to a less capable language?
(and I'm not even a Perl guy)

In a nutshell

[Troll_Kamikaze]

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.

In other words, Perl needs a book devoted to topics that are totally straightforward in a well-designed language.

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.

Re:Yes, I did

[Anonymous Coward]

She was pretty fat, you mean

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

[kisrael]

Perl 5's OO model is really, really painful.

I wouldn't recommend it to anybody. The way it makes you put different objects in different files/modules is so counter to Perl's scripting heritage that a good procedural/reusability-based outlook will get a lot more traction than this OO mess, at least 'til Perl 6.

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.

Re:Half way through

[Anonymous Coward]

I disagree that to program more complex systems you need to learn about references and anonymous hashes.

To program more complex systems you need a programming language capable of it.

That's why Perl 6 is being developed.

Re:Half way through

[hondo77]

Perl 5's OO model is really, really painful.

On the other hand, I adore it. I find it intuitive, it does just what I want it to do, and gets out of the way when I need it to. Like I tell my children, everybody is differrent.

38% off at bookpool!

[Megaslow]

List Price: $34.95
Our Price: $21.50
You Save: $13.45 (38% Off)

LOL

[squarooticus]

It took me a second to get the joke, but your point is well taken. I have taken great pains to implement garbage collection in C++, but significant understanding of the language is still required to avoid certain pessimal behaviors, which is especially problematic when others use my garbage collector. :)

honestpuck is a review machine

[billstr78]

How does honestpuck have teh time to review so many terse technical books? I wonder if these reviews are as well thought out as they could be if honestpuck was not trying to crank out 3 a week. I am going to propose the conspiracty theory that honestpuck is really an alias for a group of 10 Slash developers!

Re:honestpuck is a review machine

[stratjakt]

You dont have to read the book, or even know what it's about. Look for a post I made in this thread that got +5 Insightful. I've never read this book and I dont use Perl. Just string together a bunch of "kudos" or "boos" and toss in a couple buzzwords (K&R works fine), and there you go.

Re:honestpuck is a review machine

[Anonymous Coward]

I've had cut/paste reviews from amazon.com get moderated +5 a couple dozen times.

Once I had a review posted that was just a rewrite of some amazon.com reviews, with some vauge comments on faults based on a quick thumbing at the local borders.

Slashdot book reviews don't exist to review or criticize books, they exist for the referer money.

Re:honestpuck is a review machine

[honestpuck]

While it sometimes seems as if I'm paying the grocery bills for 10 people, no, there's only one of me.

Actually, the last three reviews published here were written over about 6 to 8 weeks and submitted to Slashdot over a 5 week period. The books were read over an even longer period, it's just that I often write reviews in a surge of two or three at a time. I'm also usually writing a couple of reviews at once as I always re-read a book after a first draft of the review.

Tony 'honestpuck' Williams

OT post

[Anonymous Coward]

BTW, I should point out that my garbage collector is better behaved than Java's: I don't have to refer to any documentation to know when the memory is going to be cleaned up, and I don't have huge 1/10-second delays caused by such events, because the behavior of the garbage collector is well-defined, even across compilers, since it's done at language-level, not at bytecode/machine code level.

Also, I can't believe Java still doesn't have templates. For shame. :( That is enough to keep me away from it unless I absolutely have to use it.

squarooticus

No

[Anonymous Coward]

Just pretty.

Re:No

[Anonymous Coward]

Was this before or after the sex change?

Please use Python instead

[Anonymous Coward]

Please use Python in the future.

At least it has a clear structure (and don't complain about the indentng issue; use an editor that does the indenting for you) and proper commands.

Perl looks like modem line noise and it expects you to know regular expressions which are just about as intuitive and easy to remember as emacs commands.

Re:"Review"?

[Anonymous Coward]

Trinity dies at the end of Gigli.

Re:fp!

[Anonymous Coward]

a failure is always a failure

I don't know

[Anonymous Coward]

When was you sex change?

Re:I don't know

[Anonymous Coward]

Just before yours, I believe.

Moderator abuse

[Anonymous Coward]

my toilet got tanked up, with stinky liquid overflowing the basin and ruining my carpeting. My girlfriend left me and a neighbor accidentally shot my dog. My credit card and identity were stolen and the thief procured three mortgages at unusually high rates in Nebraska.

And just why was this moderated as redundant?

Yes. It's a troll, maybe a flamebait, but redundant?! Fucking moron moderators.

And if you think this will be corrected by the metamoderation, think again. Slashdot moderation is utterily broken.

Re:Moderator abuse

[Anonymous Coward]

And just why was this moderated as redundant?

Apparently this problem persists for quite a few people who have bought the book and is now common knowledge. It's like saying "Linux is open-source" or "Cmdr Taco Sux". Everyone knows that so reiterating is futile.

Re:"Review"?

[larry bagina]

Thanks a lot asshole! I just wasted an hour and 5 bucks hoping i would get to see Ben Affleck and Jennifer Lopez die brutal deaths!

Next time, post a ninja-link to goatse.cx -- at least some guy's bloody asshole is less disgusting that watching b-flack and j-lo trying to act!

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.

Re:Perl is teh sux0r

[gantrep]

Because it has lots of k3wl functions. Wow, system, passthru, shell_exec and bactics? So many choices of how I can execute my perl scripts!!

Re:"Review"?

[Anonymous Coward]

It's turkey time. Gobble, gobble.

Re:Recommend Perl: The Complete Reference

[Anonymous Coward]

slashdot really needs a score -1 punny moderation.

Hear Hear!

[JohnGrahamCumming]

I totally agree. There is *nothing* in the language that forces people to write bad code with Perl (and frankly there are plenty of unreadable non-Perl projects out there).

On the POPFile project I've done everything I can to avoid Perl's temptations into obscurity by writing clear code. Amazingly I've been critized by monoric readers of the code that I could have done things with less "space" (i.e. using less screen real estate). People like that know nothing about maintenance of code and should just bug off.

If you come across Perl code that's unreadable don't blame the language, blame the author. People who write obfuscated code in any language are doing a disservice to themselves and others who read the code; if they release the code as open source then it's a _crime_ since they are inviting readers to work on their crud.

John.

Re:Hear Hear!

[cK-Gunslinger]

Amazingly I've been critized by monoric readers of the code...

Hey, you shouldn't discriminate against people with Mono. After all, it's a kissing bug, baby!

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

[Angst Badger]

This is why I laughed at the original post -- if the Camel book is a "short, sharp introduction," I'd hate to see the reviewer's idea of a sprawling book.

To be fair, a sprawling language like Perl needs a sprawling reference, and the Camel book does a decent job of it.

Personally, I don't often refer to K&R, but that's because C is a simple language that you can learn in its entirety without too much effort. Who truly knows all of Perl? Or C++ or COBOL, to mention two other giant languages? A small percentage of the users of all three. Which is not a criticism of Perl per se -- I use C and Perl and enjoy both -- but comparing C with Perl is like comparing apples and, uhm, county-fair-prize-winning giant pumpkins.

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

Obligatory Soviet Russia joke?

[Anonymous Coward]

In Soviet Russia there's more than one way to do you.

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

[Anonymous Coward]

K&R's book is entirely appropriate, when used for its intended purpose. I came to C from Perl and found K&R's book ideal. It was, after all, designed to be an introduction to C for someone who was already a quite competent programmer. I'll agree that, apart from an occasional reference, its usefulness drops quickly; after the first read-through it is largely useless. However, and importantly, I tried three other books on C first, and only K&R's was helpful. Most of the rest were either obsessed with teaching advanced C techniques, or introducing programming concepts with which I have long been familiar. The book is effective in what it does.

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

[Anonymous Coward]

Are you insane? That book is utter crap.

Bookpool?

[Anonymous Coward]

Yeah? And you'd trust your credit card number with a no-name store like bookpool?

I think not.

Re:Bookpool?

[Megaslow]

I've been buying books from them for years, never had a problem...

You'd rather support Amazon and their stupid claims that "We invented the concept of storing a credit card so you can check out faster?"
I think not.

wow

[blah1019]

Can't imagine curling up with this one

DUMBASS LIAR

[Anonymous Coward]

why are you jealous of the whore trying to get commissions from people?

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.

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!

Re:OOP in Perl is a Bad Thing

[rendermaniac]

And there are reasons there are 4 documents about it. OOP shouldn't be as hard as Perl makes it out to be. Personally I try to pretend Perl doesn't have objects and even references, because trying to use the things is a complete nightmare. This is also the point you should switch to something better designed for the task - such as Python. ISn't @ISA the biggest hack possible??

Re:OOP in Perl is a Bad Thing

[Christianfreak]

I'll concede that OO could be done better (and yes I do like Python) but if you don't understand refs then don't program Perl because refs are extremely useful things, how are they any harder than pointers in C?

Re:OOP in Perl is a Bad Thing

[hondo77]

Somebody once complained to me that I used obscure constructs in C like the ternary operator (a ? b : c). Obscure C?

One could argue that the reason expert programmers are hired is so that they will "write expert level code".

Re:OOP in Perl is a Bad Thing

[Koschei]

It's a lot easier than the amount of documentation makes out. If you had read the book the original review was about then you'd know that.

As for those tutorials: perlbot is more a quick cookbook reference type thing; perltoot is part 1 of tchrist's OO tutorial; perltooc is part 2 and covers class data; while perlboot covers OO from the ground up.

toot/tooc are ideal for those used to OO elsewhere.
boot is great for newbies to OO.
bot is excellent as a "how do I ..." reference.

Sure, they could all do with some rewriting but those most qualified to do so (justifiably) point to "Learning Perl Objects, References and Modules" and Conway's "Object Oriented Perl". Patches welcome.

As for @ISA, it's cute and simple. Perl does multiple inheritance, so it makes sense to keep that information in an array. You can even modify this array at runtime to modify your inheritance. You can hide it all with base (despite where that link will take you, it is a core module and has been since 5.00405 [early 1999]).

What syntax would you prefer?

The startling thing about Perl OO is its flexibility.

Some heavy-handed modding here?

[Anonymous Coward]

Jeez... all he did was point out another book, OK it's about Ruby not Perl, however, the common theme is object orientation. Isn't it true that a lot of Perl-folk could gain by taking a look into Ruby if they're interested in OO programming?

The Emperor's New Perl Book

[jazztunes]

Almost every perl programmer will spout on and on about how great the Camel book is when in fact, as technical books go, it sucks. Witty, eccentric examples don't make a great book. The fact is no one wants to admit that the book sucks because they will be thought of as a fool. So they proudly trumpet from the mountain tops that nothing is better than the camel book all the while hoping no one notices that they don't understand a bit of it.

So, I will play the part of the small child in the story of "The Emperor's New Clothes" and say, "Hey wait a minute, the camel book sucks! It's about time someone else took a crack at this!"

--Jazztunes

Re:The Emperor's New Perl Book

[Anonymous Coward]

There isn't a single modern O'Reilly book that is good. Some may be good in comparison to Sam's Teach Yourself Nothing and Expand Your Ego in 24 hours, but as far as technical writing is concerned, their books are all fluff.

Re:The Emperor's New Perl Book

[makok]

Actually, the camel book is quite good. When I run into a problem in Perl and look for the answer in the camel book, I often find it.

Perl Readability

[crucini]

$foo{$bar}{$foo2}

This shouldn't be confusing. How about foo[ bar ][ foo2 ]? Indexing into a 2-dimensional array in C. Your example is the same except that we index associative arrays.

Must-have if you enjoyed "Learning Perl"

[Sky Lemon]

Great book and a must-have if you enjoyed "Learning Perl" and would like to round out your knowledge of the language. Daimon Conway's "Object-Oriented Perl" is also a great book and would follow nicely from Randal's if your objective is to write good OO code in Perl.

Even though I already have Conway's book I still picked up Schwartz's since I need a quick refresher and Schwartz has a knack for being clear, concise and congenial for the real-world programmer.

Definitely consider picking it up if your working on a moderately complex project that would benefit from better code organization and maintainability. Using references, modules and objects is essential in such situations.

Strange...

[screenrc]

The C syntax is horrible, have you programmed
in other languages in order to see the difference?
I can think of at least 2 languages that are
50 miles simpler to read.

But syntax is not a major issue anyway. The
main issue is the capabilities of the language.
Apparently, those who speak on issues of syntax
and general look-and-feel have no knowledge
to talk about the more techincal issues. So here
here you have it: 1000 posts about how the
language "feels", and we are going to skip
the hard technical issues which you have
not heard about, much less know them!

No wonder non-techincal issues like SCO vs. IBM
receive record posts. Same reason here with syntax style.

Re:Strange...

[wideBlueSkies]

>>The C syntax is horrible

Oh, and what's better? Java? C#? C++? COBOL?

You are incorrect in your assumption about tech knowledge as it relates to conversation about look and feel. Both subjects should be important to those who write code for a living.

Tech issues? Which ones are important here? Please speak up and share your wisdom.

wbs.

Re:Strange...

[screenrc]

Yes, C syntax is horrible, at least when
compared to Lisp, Basic, and Rexx .

You imply that you make your living in programming and
that the "feel" of a language is important. Why?
As a programmer you should know that the "feel"
of the language is probably the least of your
worries. You know what other issues are important,
but since you have to ask, and I don't feel
like embarking on 3000 word essay, lets only
mention that the capabilities of the language
is more important than "feel", yes, and we are not
fagots. Who about the ability to alter the parse
tree? How about coninuations? How about arbitrary
types of dispatch resolutions?

No you are not impress me by saying that C has
simple syntax since I already mentioned languages
that have better.

No you are not impress me by saying that syntax
is very impartant. I would rather do with worse
syntex if I can powerfull features from the language to manage complexity.

Re:Strange...

[Slack3r78]

Comparing C to BASIC? On the off chance that you're not a troll, C syntax becomes very natural once you've been working with it for a while. It's like anything, there are tradeoffs between usability and raw power, and C leans more towards power and the cost of some ease of use. However, C (and more so C++) code tends to be a little less obsfucated in my experience - be it due to syntax, culture, whatever. I can definitely understand why this guy would lean towards mimmicking it when possible. Either way, the languages in question are for accomplishing very different goals, and if a programmer can find a way of making an unfamiliar language easier for them, this is generally a Good Thing(TM).

Re:Strange...

[screenrc]

The comparison was not only with Basic, it
was also with Lisp and Rexx, both of which
are powerfull.

But powerfull is not the issue. The issue is
whether *I* think that the C synstax is horrible;
a subjective call, and for me it is.

Although our conversation is not about powerfull
language semantics (our primary issue is syntax
style), indeed, the more powerfull the language,
the more complex will be the syntax. It is like
a baby-talk vs adult language complaxity.

(As for C++, no, it is a just tiny 1-year baby when compared to
Lisp or Parrot Assembly)

Short?

[James Lanfear]

It certainly appealed to roughly the same audience, those who wanted a short, sharp introduction to a programming language.

I like the Camel Book, but short it ain't. The Third Edition is 1067 pages. For that much paper you can have K&R2 and Advanced Programming in the UNIX Environment, or the ISO C spec and a pretty complete POSIX reference, or almost half of the GCC manpage.

Can somebody tell me where to find 'K & R' Boo

[Anonymous Coward]

As the intro says, the K & R books are the bees knees when comes to introducing C to programmers.

Can anybody provide a link?

Re:Can somebody tell me where to find 'K & R'

[nighty5]

Try;

http://www.amazon.com/exec/obidos/tg/detail/-/01 31 103628/qid=1060164149/sr=8-2/ref=sr_8_2/104-927662 1-2139163?v=glance&s=books&n=507846

Re:Can somebody tell me where to find 'K & R'

[nighty5]

C Programming Language (2nd Edition)
by Brian W. Kernighan, Dennis Ritchie, Dennis M. Ritchie

For some reason the link doesnt work :)

C# or Java

[makok]

I think you've missed the point if you try to do object oriented in Perl. If you want to do objects, use a language that was invented with objects in mind such as C# or Java.

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

[cmarkn]

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

There is only one C++ spec. You can get it from the ISO store.

Good book

[sad_]

I got this book a few weeks back. This is really a nice book. It does not have a high page count, but still contains a lot of information. Ofcourse this book is not for everybody.

Are you using perl now? You know it well enough to get most of your things done fairly quickly and easily. Typicly you don't write large perl scripts but sure would like to and would like know more perl. then buy this book, it will tell you most of the stuff you're missing.
Some people here argue that all the information is in perldoc etc. but this book is never the less nice, if only for the exercises after each chapter.