Why Perl?

So why Perl, then, and not Visual Basic, Tcl, or Python?

Although Visual Basic is an excellent choice on a Wintel[ 3 ] PC, it's not around on any other platform, so it has not been a practical choice for me.

[3] Wintel: The Microsoft Windows + Intel combination. I'll henceforth use the term "PC" for this particular combination and explicitly mention Linux and the Mac when I mean those PCs.

Tcl forces me to go to C much earlier than I want, primarily because of data and code-structuring reasons. Tcl's performance has never been the critical factor for me because I have always implicitly accounted for the fact and apportioned only the non-performance-critical code to it. I recommend Brian Kernighan's paper "Experience with Tcl/Tk for Scientific and Engineering Visualization," for his comments on Tcl and Visual Basic. It is available at http://inferno.bell-labs.com/cm/cs/who/bwk .

Most Tcl users are basically hooked on the Tk user interface toolkit; count me among them. Tk also works with Perl, so I get the best part of that environment to work with a language of my choice.

I am an unabashed admirer of Python, a scripting language developed by Guido Van Rossum (please see http://www.python.org/ ). It has a clean syntax and a nice object-oriented model, is thread-safe, has tons of libraries, and interfaces extremely well with C. I prefer Perl (to Python) more for practical than for engineering reasons. On the engineering side, Perl is fast and is unbeatable when it comes to text support. It is also highly idiomatic, which means that Perl code tends to be far more compact than any other language. The last one is not necessarily a good thing, depending on your point of view (especially a Pythoner's); however, all these criteria do make it an excellent tool-building language. (See Chapter 17, Template-Driven Code Generation , for an example). On the other hand, there are a lot of things going for Python, and I urge you to take a serious look at it. Mark Lutz's book Programming Python (O'Reilly, 1996) gives a good treatment of the language and libraries.

On the practical side, your local bookstore and the job listings in the newspaper are good indicators of Perl's popularity. Basically, this means that it is easy to hire Perl programmers or get someone to learn the language in a hurry. I'd wager that more than 95% of the programmers haven't even heard of Python. 'Tis unfortunate but true.

It is essential that you play with these languages and draw your own conclusions; after all, the observations in the preceding pages are colored by my experiences and expectations. As Byron Langenfeld observed, "Rare is the person who can weigh the faults of others without putting his thumb on the scales." Where appropriate, this book contrasts Perl with Tcl, Python, C++, and Java on specific features to emphasize that the choice of a language or a tool is never a firm, black-and-white decision and to show that mostly what you can do with one language, you can do with another too.