Perl for C Programmers (Learn)

Features

• Cover Type: Paperback with 432 pages
• Published by: Sams
• Edition: 1st Edition July 26, 2002
• Written in: English
• ISBN 10 Number: 073571228X
• ISBN 13 Number: 978-0735712287
• Book Dimensions: 9.1 x 7 x 0.9 inches
• Weighs: 1.5 pounds

Book Description
The Perl book written for the C and C++ programmer. Perl for C Programmers teaches what's similar and different between Perl and C/C++ and how to then utilize Perl to the fullest. 80% of the people who start using Perl for the first time come with a background in the C or C++ programming language. This book is written for those people. Perl is becoming one of the most common languages used in web development because of its powerful ability for text manipulation. There is a large need for Perl books that clearly explain how to use Perl in terms the reader can understand. The primary audience coming to learn Perl is C and C++ programmers.

About The Author
Steve Oualline is the author of many programming and Linux related books. He is a professional software engineer, author, and educator. Currently, he works for a large software company as a quality engineer devising ways to improve the quality and reliability of the code produced by their programmers. Other books by this author include Vi iMproved (vim), 0-7357-1001-5, New Riders, 4/01, Practical C++ Programming, Second Edition, $39.99, O'Reilly, and Practical C Programming, Third Edition, $34.95, 1-5659-2306-5, O'Reilly, 9/97.

Reader Reviews
After years of trying, I've finally learned Perl. And it's all thanks to this book. My biggest obstacles to learning Perl have always been: the language's twisted, almost willfully obscure syntax, and the chattiness, annoying humor, and equally obscure tone of the language's leading book for beginners, which I will leave nameless (hint: there's an animal on the cover.) It often seems as if both the book and the language take a perverse pride in being so arbitrary, riddled with exceptions and special cases, and overly complex. I'm sure most Perl people will disagree with me, but most Java and C/C++ folks I know would not. We are really past the point in history where it's funny or cute for a language to be so difficult and obscure. More than ever, time is money, the latter of which is in far shorter supply since the dot-com crash. We (and our bosses) just want to get things done. Not everyone wants to be a funny hacker with a funny t-shirt who thinks it's funny when no one else can understand their code. Unfortunately, while Perl is the champion of the heavy-lifting in text processing, its extremely flexible and often counter-intuitive syntax can make these benefits inaccessible to many programmers. Furthermore, the unnamed introductory book has a chatty folksy, verbose tone that seems to deepen and celebrate these faults. Oualline's book turns out to be the antidote. Using a brief, business-like tone, the author brings the logic and organization of the C language to bear in his approach to teaching and using Perl. Here's a quote from the book that sums up Oualline's mindset: "Perl's designers have stated that their philosophy in designing Perl is 'There's more than one way to do it.' My philosophy is a little different: 'There is only one clearest way to do it.'" Basically, by taking a single, C-flavored route through Perl's syntax, shunning its more confusing and counter-intuitive elements, Oualline provides you with an empowering, working knowledge of the language. Once he gets you there, you finally see just how awesome a language Perl can be, particularly for reporting and system administration. In short, Oualline teaches you to speak Perl with a C accent. One example of this is the way he recommends that you write Perl subroutines. Contrary to nearly every published piece of Perl documentation, he tells you to declare all of them with parameter specifications. That is, if you are writing a subroutine called "do_it" that will always accept two scalar parameters, write: "sub do_it ($$) { . . . }" instead of "sub do_it { . . . }". Sure, this is less fun and less flexible than not specifying parameters, which Perl will allow you to do. But in Oualline's opinion, "[that] form of parameter passing should be avoided. By using a parameter specification, you give Perl the capability to do valuable parameter checking. Leave out the parameter specification, and you invite chaos." Like I said, this goes against all conventional Perl wisdom, but for people who are used to mainstream, highly-structured, strongly-typed languages, it definitely makes thinking about Perl much easier. The book has a few flaws and omissions. For example, while stressing that we should specify parameters, Oualline forgets to mention that this means we must either put subroutine declarations at the beginning of a progam, or use forward references. Given his emphasis on parameter specification, he should have mentioned this. Also, his discussion of parameter passing is incomplete - he does not explain how directly accessing the @_ array in a subroutine will alter the caller's copy of the parameters. Then again, the other introductory book I mentioned doesn't cover these facts, either. I had to dig through perldoc to figure all this stuff out. Finally, a chapter on accessing databases from Perl would have been nice. This book is not for everyone. If you want to learn Perl in all its gory details, and, more importantly, if you want to adopt the style and mindset of the Perl programmer, then you probably will want to look to another beginner book. Ditto if you're the kind of programmer who's more interested in playing syntactical games than in designing an effective architecture. However, if you are a programmer of C/C++, Java, or a similar language, who just wants to get things done effectively, clearly, and quickly, then this is the best route to go down. Comment | | (Report this)