Slashdot Mirror
Programming Perl, 3rd Edition
The Scoop Longtime Perl fans know Programming Perl as the Camel, because of the cover animal. With the first edition in 1991, Perl programmers gained not only a charmingly appropriate mascot, but the ultimate language reference. True to form, this Camel's grown with the language. In the four years since the last release, it's increased in size by 67%.
Everything you liked about previous editions has returned, in one form or another. Additionally, this third edition covers the largest changes made for Perl 5.6 (actually 5.6.1, as the book's ahead of the current stable release by a bit) -- Unicode, threading, and more Perl guts.
While the previous editions were exceptionally well-written references, they were also aimed squarely at experienced programmers. This edition pushes back the starting blocks somewhat, providing a gentler introduction to the world of Perl. The wealth of new information is staggering, but as you'd expect from the luminous authors, even the core language reference is highly readable and entertaining.
What's to Like? Logically, the book is divided into five main sections. (Gone are the massive 80-page chapters of the second edition). The first section, one chapter, gives a good overview of Perl, as a language and a philosophy. It includes a quick introduction. The second section gives the language's gory details, covering just about everything you would need to know. It's arranged in terms of ascending complexity. The enhanced, extended, and improved regular expression chapter stands out as the best member of this group.The third section discusses Perl as technology. Here's where Unicode comes in, as well as the internals of Perl (through the internal compilation process, using the debugger, or using XS to extend Perl with C code). Everything here is quite good. Expectably dry subjects like Unicode or threading are readable and even a little entertaining. If you're not convinced, you can skip around and still learn quite a bit.
The fourth section is devoted to Perl as culture, with discussions about portability, security, good practices, documentation, CPAN, and a bit of poetry. The security chapter is quite good, but left me wanting more information. Any chapter here is accessible if you've made it through the second section, so feel free to pick and choose what you need to know.
Rounding up the spare bits is the reference section. Not only will you find descriptions of the special variables, built-in functions, and standard library, but the organization and presentation of these descriptions has improved. Functions have little annotations listing which magic variables they set, possible exceptions they raise, and the like. That accounts for 150 pages of the overall goodness. Don't skip the glossary at the end, if you're confused or looking for amusement.
What's to Consider? While it's a temporary conundrum, it's a little odd to read about features that aren't quite implemented yet. This is most noticeable in the Unicode discussions and the chapter on threading. Occasionally, the authors will describe a feature and then admit that the specifics will likely change. (Have a look at the documentation.) Granted, the bulk of the language is mature and stable, and the definitive guide can't very well get by with ignoring major features, but it reads a little oddly.The intended audience is still the serious Perl programmer. Dabblers and casual learners will find enlightenment and instruction. Realize, though, that while it's easier to start your journey here, absolute beginners would do well to explore a Learning Perl or Elements of Programming with Perl first. People who've programmed before (beyond dabbling with VB, or doing mouseovers in Web pages) should have little difficulty picking up the Perl language and mindset.
The only other possible improvement that comes to mind is expanding certain chapters. As noted before, there's more to say about security and efficiency. It would also be nice to have a chapter on common Perl idioms one might find in EFNet #Perl or at Perl Monks, or the latest Perl Mongers meeting. (Half of the fun is discovering and sharing new tricks and shortcuts.)
The Summary Part of being a good programmer is knowing where to turn for accurate and useful information. This is the place for all things Perl. If you use Perl regularly, put the new Camel on your shelf. Table of Contents- Overview
- An Overview of Perl
- The Gory Details
- Bits and Pieces
- Unary and Binary Operators
- Statements and Declarations
- Pattern Matching
- Subroutines
- Formats
- References
- Data Structures
- Packages
- Modules
- Objects
- Overloading
- Tied Variables
- Perl as Technology
- Unicode
- Interprocess Communication
- Threads
- Compiling
- The Command-Line Interface
- The Perl Debugger
- Internals and Externals
- Perl as Culture
- CPAN
- Security
- Common Practices
- Portable Perl
- Plain Old Documentation
- Perl Culture
- Reference Material
- Special Names
- Functions
- The Standard Perl Library
- Pragmatic Modules
- Standard Modules
- Diagnostic Messages
Glossary
Index
You can purchase this book at ThinkGeek.
Next
(Those books don't last like the old ones used to)
I wouldn't have expected a third edition of the camel just now. Isn't Perl6 coming out Real Soon Now? I understand it will introduce some significant new capabilities. Given that, I'd have waited.
--
Some keywords for the NSA in the Lord of the Rings universe: One Ring bind find Sauron quest Nazgul freedom
Would I walk a mile for a camel?
I guess you don't smoke...
People replying to my sig annoy me. That's why I change it all the time.
--
A feeling of having made the same mistake before: Deja Foobar
While electronic books can easily fix this problem, that's not the solution when you need to look at paper copies, whether at the terminal or on the toilet. Maybe there should be some way to 'register' the books, such that when the n+1(th) edition comes out, you can get it for a substanially less cost, because your initial purchase of the nth edition helped to make the n+1(th) edition possible. Or one could send in the cover of the nth edition and a S&H charge to get a copy of the new book. Or something along these lines.
If any computer book publishing company could do this, I would expect ORA to be the first to try such, given their helpfulness in the past and present. But with many standard 'things' moving so fast (XML, HTML, Perl, Python, etc), we need a some book upgrade mechanism in place ASAP.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
For those who wish to be a little too hard core. The 1st edition which only covers version 4 is perfect intro to perl. After that, work your way through the man pages (in HTML). You'll notice many of the perl books are rehashes of the man pages. (I use man pages loosely, since all the perl docs can be seen in HTML and mush easier to read and navigate).
Perl isn't ideal for Slashcode (it's too large and crappy, other technology would be better). It is really good for knocking up quick scripts... Want to rename a bunch of mp3 files so they don't have spaces in their name? Perl's for you. Want to rename mp3 files based on CDDB information? Perl's for you.
I just picked those off the top of my head, but I use Perl daily for small scripts to cut out mundane shell typing. It's also ideally suited to build scripts and environments.
I know it's been talked about before, but it seems odd to try to buy computers that have rapidly developing feature sets, such as CDRW, 3D video, USB ports, without some mechanism for the user to get the next version or three at a free or reduced cost. (Mind you, Tiger direct computerss are generally inexpensive, but this is true for all publishers).
Certainly has having used the 286 processor, I know that computers has changed a lot in 7 or so years, and much of my 286, while not fully useless, doesn't fully cover what I need to know nowadays for computing. I've been hestitent to buy the more recent computers because I see the same problem happening in another 2 or 3 years. As this review points out, some of the features on USB and 3D video when the next generation computers are released, making this computer useless.
While code morphing can easily fix this problem, that's not the solution when you need to be productive. Maybe there should be some way to 'register' the computer, such that when the n+1(th) edition comes out, you can get it for a substanially less cost, because your initial purchase of the nth edition helped to make the n+1(th) edition possible. Or one could send in the cover of the nth edition and a S&H charge to get a copy of the new computer. Or something along these lines.
If any computer book publishing company could do this, I would expect ORA to be the first to try such, given their helpfulness in the past and present. But with many standard 'things' moving so fast (XML, HTML, Perl, Python, etc), we need a some book upgrade mechanism in place ASAP.
you're looking for a perl _interpreter_.
and you'll find it at http://www.activestate.com
perl development kit?!? well, you already have notepad.
complex
Or did you mean, more like IndigoPerl? Perhaps you aren't aware that Perl has been available for Win32 systems for over four years, and that it's been ported to almost every other OS under the sun...
Or, more than likely, IHBT.
Free music from Jack Merlot.
Anyone looking to use Perl for administration could do a lot worse than read Perl for System Administration.
I would be a paid subscriber if Taco and Hemos weren't such cunts
No offense to the people who took the time out of their lives to write slashcode, but IMHO it's a pretty bad example of a big application written in perl.
Exhibit A: when a perl file starts out with "use strict; # ha ha ha, not really" or a similar comment
Exhibit B: global hash vars used for configuration information that have names like %I (real descriptive, guys), and that are never centrally declared (ie. the components are assigned piecewise throughout a ton of different files, not one central declaration of "%I = (stuff)" in an obviously named file.) (note also that %I is not the sole conveyer of conf info, further muddying the waters)
This is not to say that slashcode is bad in terms of utility, on the contrary, the slash engine itself works quite well (as /. and any number of other slashcode sites (like the 3 I've set up) demonstrate). Heaven help you if you want look at the code though...
Like any language, a large part of it's suitability for a given task depends on the coder as well as the language's unique attributes. I've seen just as bad C and Python as I have perl.
(In the unlikely event a central slashcode maintainer reads this post: dude, try enforcing (recommending, whatever) a minimum 4 or 5 character variable name convention! It'll increase the readability (and thus ease of contribution) a good bit. :-) )
--
News for Geeks in Austin, TX
I know Tom's skills are widely heralded by many, but I'm not all that fond of his "There is ONE way to do it - my way, and nothing else, damnit!" attitude. Sure, he's a smart guy, but that doesn't make it his place to dictate how something must be done in perl, when there are perfectly good alternatives.
For instance, I recall one time when he flamed my butt off for using the OO syntax that's possible with the CGI.pm module. I pointed out that my code was perfectly valid, and no more or less valid than his "counter-example" to my code, which did not use the OO syntax. Nevermind the fact that even the docs that come with the module describe it as perfectly valid syntax.
Sure, he's a smart guy, and probably overall an asset to the perl community, but watch out for the other edge of his "sword", so to speak.
>>Although that was a long-awaited update (although it disappointed in some respects compared with the original), the differences between 5 and 5.6 do not really warrant buying a new edition. <<
At my local Perl Mongers meeting, I looked at the 3rd Ed Camel for ten minutes (I own the second). I was instantly convinced of its superiority. You may consider Unicode a minor feature, but for people who need to work in other languages than English, it's a major help. Further, Larry Wall is funny enough that a new edition (with new humor) is worth buying even if you never intend to use Perl (it helps to be a geek, tho - look in the 2nd ed. camel under the Glossary for "thread" to see what I mean).
Become a FSF associate member before the low #s are used
well, you already have notepad.
Or, you could use Emacs - which is also available for Windows.
Steve
---
Seriously, I don't see much use for perl other than for programming server-side applications (i.e., the Slashcode which powers Slashdot's forum system, etc.). Until I do get into the server world, I won't need it.
That's like saying an 18-wheeler's only good for hauling cargo.
What, you were planning to write a first-person shooter in Perl?
btw, PerlTk _is_ cross-platform, so in theory if you needed a GUI app in Windows, you could do it. Did it myself (wrote a list viewer in <100 lines for some CSVs), though it wasn't particularly fun. Perl can do anything useful that VB can, and it can do it across dozens of platforms.. Not that it's the optimized solution, or the easiest solution, or even the fun solution. But you can take Perl with you to any task (client-side data parsing and munging results from DBMSs, server-side web/analysis stuff, sysadm, etc) and get it done.
(and for all you Perl maniacs, that FPS thing was NOT a dare!!! Please don't inflict such a beast on humanity...)
Your Working Boy,
Don't blame Perl if your code is too messy to maintain. TIMTOWTDI - Perl lets you write bad code, but it lets you write great code too. Quick hacks for when quick hacks will do, Packages and O-O for when they won't.
What's your problem with OO in Perl? It's really nothing to be frightened of (I was, but then I tried it). Create a Package, create an object, bless it into the Package. Easy-peasy. For the hard stuff get the Damian Conway book, it's a classic.
I'll be buying Camel v3. I am one of the few people I know who learnt Perl without a Camel (I just read the perldocs. Probably not recommended though!).
"What I look forward to is continued immaturity followed by death."
From the time I've spent reading through the 3rd edition, I've already come away with a lot of new insights that I somehow never picked up in my 8 years of working with the language. I highly recommend the 3rd edition as the most readable and informative to date. I like the 3rd edition book far more than I do the 2nd edition, and that alone justifies the publication of the new book, Perl 6 or no Perl 6.
As for all the general flaming on Perl here, I have to say I'm a bit surprised.. Perl is still by far my favorite way of doing systems administration scripting, both on UNIX and NT. It seems like whatever I work on, a bit of Perl added to the mix Makes It Better. I can't count the number of times I have wished that /bin/sh was a Perl interpreter.. it would make bootstrapping install scripts on an arbitrary UNIX system a lot easier.
Or are people here *that* enamored of autoconf?
Anyway, best edition yet, and a damn fine job by Mssrs. Wall, Christiansen, and Orfant.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
NTAGARA
I love perl. Despite the current fashion for the peeps to distain it, it is a fantastic language for getting things DONE.
And I don't mean just "quick'n'dirty" stuff either; I'm talking about enterprise applications that live for a long time. I have an LDAP replication daemon, written in perl, that has been running strong for two years, thank you very much.
Perl is like English. It can be very dirty and ugly when written so, but it can also be so beautiful as to be sublime. And unlike "bondage and discipline" languages (*cough* Java *cough*) it gives you the freedom to code in an accent when needed - adapt the code to fit the problem, not the problem to fit the code!
Those that complain that perl is illegible or hard to understand just haven't seen perl written as to be maintainable - tip: don't use Slashcode as a starting point.
And as for Tom Christiansen... how horrible that there exists someone who stands up for code quality, and is willing to speak his mind!
Long Live perl!
Want to learn about race cars? Read my Book
Randal Schwartz, beyond his Perl exploits, hacked his former employer Intel, allegedly stealing passwords, and did some hacking of O'Reilly Associates. Probably politics between him and ORA, due to his lack of discretion. His, the first ORA Perl book, was enjoyable, due to his offbeat hacker humor. A less dry experience is helpful when trying to learn from a book. Then, too much humor and it can be quite frustrating. I think he provided a good balance. Randal could often be found on USENET groups, to pick his brain on various Perl problems. Always a fun guy to chat with. I wouldn't be surprised if he reads Slashdot.
--
A feeling of having made the same mistake before: Deja Foobar
My favourite exchange involving Tom and an AC on /.
:)
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
People are working on a Python equivalent; give us (me, mostly) a few months...
Forget all this vi vs. emacs foolishness. Why not use a REAL editor?
teco for Windows.
Yes, it's still around.
--------
Bill Gates Is My Evil Twin.
"Most people."
Nice try, generalizing your personal experience. Guess what, doesn't work.
I'm moving to Ruby AND staying with Perl.
--------
Bill Gates Is My Evil Twin.
Hmm. How many incorrect statements can be made in a single /. comment? This one is in the running for the record this week anyway.
1. Randal did not "hack his former employer." Randal was not an Intel employee; he was a sysadmin on contract. Those of you who have been contract sysadmins understand the issues.
2. He can and does speak for himself on this issue, but my understanding is that he was performing fairly ordinary security reviews for his then-current client. Due to what might be described as a personality conflict with another Intel person, his activities were "escalated" (insert wry telecom reference) to the point where PHB CYA mode kicked in. The company over-reacted and the matter was referred to the supine Washington County, Oregon district attorney. A Keystone Kops scenario of Randal's home being invaded by Law Enforcement Personnel, weapons drawn, ensued. Randal tried to persuade them with his notion of the truth, but it didn't matter; the CYA mode is one-way and the company felt impelled to 'accede' to the county pressing charges.
3. A show trial ensued with a judge misinterpreting both the law and the facts. Randal was convicted and received a suspended sentence and a major fine. His case is STILL ON APPEAL.
4. The lesson is here is, never forget the famous cliche "no good deed goes unpunished." Especially for those of you involved in security-related system administration. Especially when you type su
5. Hmm, come to think of it, that means all of us who manage even a single box for just one other person.
6. Randal did not "hack" ora.com. Child, where did you get these notions? Actually, I will say this, when Randal ran crack on Teleport around that time, James Deibele told him to knock it off. Then Intel and Washington County decided to throw the book at him and try to make a big bad example out of him. The way things are going it could have meant a jail sentence. As for the fine and court costs, my recollection is: $300,000. Look at those zeroes. There are a lot of them.
8. Much of the humor in the first Camel is a blend of both Larry Wall and Randal Schwartz. It remains a unique contribution to the literature of computer science.
9. "Probably politics between him and ORA." No. Read my friend Steve Silberman's piece in Wired, and you will get a much clearer view of what is going on in the Perl world. I feel very badly for Randal that after all he's done this is the kind of treatment he gets, including completely lazy, ill-informed hearsay from the likes of this 'ackthpt'.
10. "his first ORA book". No. Go read the cover, or better yet read the book. There are TWO names on the cover.
11. "I wouldn't be surprised if he reads Slashdot." You know, the Search box is your friend.
It would be so nice if everyone would engage brain before steering fingers. But this is asking for the world, I know . . .
-------
Bill Gates Is My Evil Twin.
do you have a link to the piece in Wired about the perl world?
A good place to find some info and related links Beyond Mark Morrissey's report it's kind of boiled down to a "Did not-Did too" argument. I've not taken any side in the debate, but it is a case worth reviewing if you ever feel the urge to test security without having a job description or contract outlining that as your responsiblity.
--
A feeling of having made the same mistake before: Deja Foobar
Oh, this is rich:
"How do you formally verify a perl program for correctness?"
You compare the output to the input and the program specifications, and if the program does what it is supposed to do, it is correct.
Here's a tip from a real programmer, Java-boy: just because it *compiles* doesn't mean that it *works*
Want to learn about race cars? Read my Book
I've jumped between a bunch of programming languages when doing OO programming. Perl's way of doing things is more flexible than any other language I've seen. But if you want hard-core rules, well you can do one of two things:
Python, while kind of neat, is too hard-set in its rules. Perl is more like the Jazz of programming languages. Python is sort of like, well, classical music. I like Jazz better BTW :^)
--- Journals are boring; Go to my web page instead