Customer Reviews

Perl for C Programmers (Landmark)

5 star:		(3)
4 star:		(1)
3 star:		(0)
2 star:		(1)
1 star:		(0)

 

 

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.

As the title of the book suggests, this is targeted at C (and C++) programmers. You know, we C programmers are the best in the programming world, because C is such a great language. The problem for us is, it's so hard to migrate to Perl, which is at the same time forgiving (no need to typedef any variables) and unforgiving (mistakes are hard to track down). I don't like Perl. For me its mantra "there's more than one way to do anything" signifies everything that's wrong with it. Reading someone else's Perl code is even more of a nightmare than reading C code. With C, once you understand all its shortcuts, you can understand any C code. With Perl, even if you are a seasoned Perl programmer, someone else's code can still drive you nuts easily and shortens your life by a couple decades.

Anyway, enough rambling. "Perl for C Programmers" wants to help us C programmers make the transition to Perl. It's an easy read and you can follow the explanations and code examples easily. You can pretty much grasp all the basics in no time, as the book quickly goes through how things are done in Perl vs. in C.

However, this book seriously lacks depth. First of all, a lot of important Perl constructs such as hashes and references are not explained clearly or in detail. If the camel book ("programming perl") is *too* detailed to the point of ad nauseum, this book is too shallow, and if you just rely on this book to learn Perl, you still won't be able to understand 80% of the code you might encounter. Second, the book gives only superficial treatment on the differences between C and Perl. Third, the book all too often scratches the surface of a topic, then refers you to the notoriously hard-to-read perldoc online docs for more details. For example, the sort() function is probabably one of the most important text-processign functions an everyday Perl programmer uses, and it's a rich function (to the point of frustrating many a poor Perl programmer), but the book only gives a very passing description.

What I noticed about the book -- and which pissed me off given how expensive this book is compared to other Perl books -- is it wastes a lot of space on stupid in-code comments (like the ridiculously looking arrowed comments for regexps) and regexp debug output (several pages long for somethign you'll probably never *want* to know). The feeling after reading the book was really one of emptiness, like the $18-per-head buffet I had last month on the Scotia Prince ferry that only served lettuce and tomatoes and roast beef and lobster shells.

Instead, I recommend starting with "Sam's Teach Yourself Perl in 24 Hours" if you want a quick kickstart on Perl, and "Sam's Teach Yourself Perl in 21 Days" if you have more time to learn. Then be sure to read the camel book "Programming Perl" for the finer subtleties of this frustrating beast called Perl. (You can skip the "Learning Perl" book as it has very little value-add.)

I started a job where I was forced to use perl, this book became incredibly useful. I use it to write perl code that makes sense to me. Most other books I've read didn't get me nearly as far in as short of a time period. My background is C/Assembly programming, so this was perfect. I recommend it for those who want to learn perl, by choice, or not.

I'm a C/C++ guy so I bought this book after seeing the title and browsing through it. It is a very good book. It goes over a lot of topics, comparing how C does things to Perl (each of which has advantages in different areas). The author writes in a clear and concise manner. He could go in more depth in certain sections, but overall I was pleased.

My primary involvement with programming has been C/C++ for a couple of years. This book hits the sweet spot for me with regards to bridging the knowledge gap between the two programming languages. I soon realized that Perl is not C and it needs to be treated on its own merits and way of thinking. Because there are many Perl concepts that really have a different twist than C, it is difficult sometimes to get a straight answer about some quirk without getting drawn into hours of scouring reference manuals in order to solve a problem.
For me this book makes is the perfect translation manual I needed to quickly get up to speed with Perl's method of working and idiosyncrasies.
It might not be primary reference book on Perl, but I found that this book along a good reference book on Perl I could be up and running on the language surprisingly quickly.