Advanced Perl Programming

IMMERSE YOURSELF:

Storage & Servers

Advanced Perl Programming

Reviewed by Donald Bryson

Advanced Perl Programming

Book cover (4K)

By Sriram Srinivasan
404 pages. 5 pages of contents; Appendix; 11 pages of index
ISBN 1-56592-220-4, paperback $34.95

Available at a discount from Amazon.com on this page

Technical Level: computing -- experienced, subject -- experienced
Information: concepts: good; practice: excellent
Readability: textbook: spectacular; reference: good
Summary: An in-depth discussion of some of the advanced topics of Perl programming: interfacing with databases, networking, Tk, and the internals of the interpreter.

Publisher:
O'Reilly and Associates, Inc.
101 Morris Street, Sebastopol, CA 95472

Review

Have you ever read a book with the uneasy feeling that the author had a hidden agenda? That's the feeling that I had with Advanced Perl Programming. Halfway through the second read it hit me -- Srinivasan is trying to trick us into being efficient.

Well, trick isn't exactly fair. He actually states in the preface, ``... it would be most gratifying, or totally tubular, as the local kids are wont to say, if the design patterns and lessons learned in this book help you even if you were to choose other languages.'' So, he does give fair warning that he is teaching methodology, not mere gee-whiz kludges.

His methodology consists of four recurring themes:

Be modular. A significant portion of the book discusses modules, packages, objects, and classes.

Use a two-language approach with large applications. Srinivasan is a proponent of marrying a high-level language with a low-level language when crafting large applications. This gives you the best of both worlds. You can build fast trick code, use fine-grained data types, and shift bits to your hearts desire with C. Combine that with a high level language like Perl to build the user interface and you have a dynamite couple. He demonstrates this marriage eloquently with an example of using Perl and C/C++ to draw fractals.

Use the tool that best matches the task at hand. For example, Srinivasan gently compares X with Perl/Tk. After a quick quote of ``... programming X is like taking the square root of a number with Roman numerals,'' he easily constructs a Tetris game with Perl/Tk.

Know your high-level language from the ground up. Srinivasan believes that, ``... you can never be a good programmer if you know only the syntax of the language, but not how the compilation or run-time environment is implemented.'' As an example, he describes why passing a reference to scalars typically is not faster than passing the scalar itself. Referencing and de-referencing the scalar consumes any saving.

This isn't a book for casual reading. You must think about what Srinivasan is actually saying and use his advice with common sense in the context of your own goals, experience, and methodology.

It's too easy a jump from dissecting Perl to making a hypothesis about some black box. Srinivasan's methodology is not assume-and-code; Srinivasan's methodology is know-and-code. The Perl interpreter is like a glass box because the source code is freely available. Make a clear distinction in your mind between a glass box look-and-leap approach and a black box program-and-pray one.

Assumptions are always dangerous. For example, I created a C library for Xbase files several years ago. The format of the header record of a DBF file isn't a published standard. I guessed on some of the fields in the header. Some programs could read my files and others couldn't. Why? How should I know? Remember, assumptions are always dangerous.

I have reservations about looking too closely into any box -- black or glass. Contrary to my normal policy of never discussing a book review with author prior to its publication, I contacted Srinivasan for clarification of his views on interfaces and implementations. He distilled his glass box methodology via mail, which is reproduced here:

It's like having one of those transparent watches where you can see and appreciate the machinery, but don't intend to tamper with it in any way. Or like a race car driver who can tell from the sound of the engine if something's wrong, because he knows how the engine is built.

That's a reasonable methodology. It's one that mimics what we do in the physical world. However, in my opinion, examining the mechanics inside any glass box still has risks with the benefits.

For instance, His approach results in coupling, where coupling is a program's dependency on the box's implementation instead of its documentation. The Perl source code is its implementation. The lexicon of the language is its documentation. Coding based on the implementation could cause you problems with later releases of any box. For example, an algorithm might change inside the interpreter that makes your trick blowup.

Programmers generally do coupling to some degree. Would you write a script that created 1,000 temporary files in the /tmp directory? No, of course not. File system efficiency is directly related to the number of files in a particular directory. That's coupling but it's also practical.

You must temper your need for a coupling optimization with common sense. All optimizations are not the same. The trick is weighing the benefits with the risks. Compare these two examples:

Case One:
A C programmer examines the assembler output of her compiler. She notices that the source code statement y=x+1 results in assembler output that uses the add op code. She creates a small test program with the line y=x++ and notes that the assembler output uses the increment op code. She knows the increment op code takes less CPU time than the add op code, so she decides to use y=x++ instead of y=x+1 in all her programs.

Case Two:
The old Amiga/Motorola 68000 hardware interface was a clear glass box. While memory addresses were stored 32-bit, only 24-bits were used, leaving the higher-order bits unused. Many Amiga programmers used those free bits for temporary storage of application status bits.

There's quite a difference between cases one and two. No problems result for case one if the next version of the compiler creates the same output for both y=x++ and y=x+1; however, it would be catastrophic for case two whenever the remaining bits were used to address memory. Always consider what will happen if the wheels change inside that glass box.

Summary

This is an excellent book -- it's full of useful information, well written, beautifully set, and technically accurate. The section on Perl/Tk is especially strong. The examples are easily understood and easily modified to your own application.

It does, however, demand a lot from the reader. It requires a basic knowledge of Perl, C, and programming methods. More importantly, it requires the experience to know when and when not to use the advocated methodologies.

Synopsis

Advanced Perl Programming discusses three main subjects: Perl syntax, the interpreter itself, and how Perl relates to selected technologies.

Language Syntax

This section of the book does not rehash the reference section of Larry Wall's Programming Perl book. It does, however, rehash hash of hashes. :-) True to its title, it discusses only advanced topics.

Here are a few gems from the syntax section:

The real difference between the operators local and my. Now, local restores a value and replaces it at the end of a block. Functions called from within that block still have access to the variable. By contrast, my creates a truly local variable. Functions called within the block cannot access a my variable.

You can use bless to create objects with polymorphism. You can put different types of objects in the same class into different packages and then use the bless keyword to tag the object internally with a pointer to the package to which they belong. Each package would contain the same function names (but perform different particulars based on the type of object). The run-time binding then calls the appropriate module's function based on the type of object.

You can use eval to trap exceptions. For example (modified from book):

#!/usr/local/bin/perl
print "Can I continue past the division by 0?\n";
eval {
$a = 10;
$b =0;
$c = $a / $b;
};
print $@;
print "It made it past the division by 0!\n";
print "I'll never make it past the next division by 0!\n";
$a = 10;
$b = 0;
$a / $b;
print $@;
print "This line will never print!\n";

will print ``Illegal division by zero at line 6'' at the first division by zero and continue instead of dying like it does with the second division by zero.

The Perl Interpreter

Srinivasan discusses three topics relating to the interpreter: creating dynamically loadable C libraries to extend Perl, embedding the interpreter into a C program, and a nitty-gritty discussion of the internal workings of the interpreter.

Here are a few gems from the interpreter section:

You can extend the Perl interpreter by creating a new one that is statically linked with your functions when dynamic linking is not an option.
You can create a dynamic library that is loaded on demand with either one of two packages: XS or SWIG. XS is distributed with Perl while SWIG is not.
XS contains two tools h2xs and xsubpp. Given a standard C header file named mandel.h and a library of C functions named mandel.c, the following commands will create a dynamically linked library:
```
h2xs -x -n Fractal mandel.h
perl Makefile.PL
make
make install
```

Technology Areas

Srinivasan discusses using various technologies with Perl. He discusses user interfaces using Perl/Tk, databases, and networks.

Srinivasan discusses databases in two chapters. He discusses various database options with Perl such as DBI and Win32::ODBC. The network section includes discussions of RPC, FTP, and POP3.