Mac OS X Leopard - ARCAism

cover all of this goes beyond what is available in this book. Still, for those of you who are familiar
with these or those of you looking to expand your programming repertoire, it would be
remiss not to talk a bit about these languages and how they work within OS X.
Each of these languages shares a number of benefits vs. more traditional compiled languages
such as C, C++, Obj-C, and Java, including ease of use, portability, and immediate feedback
(since there is no compilation). Since they are scripting languages, all you need to write them is a
text editor, and each of these languages is free and well supported across a wide range of platforms
and devices. The other side of this coin is that interpreted languages such as Perl, Python,
and Ruby (and shell scripts for that matter) have a few disadvantages vs. their compiled
brethren: they lack the performance of a well-optimized compiled program; they are not as well
suited for low-level programming tasks; and if you choose to distribute your script, you are also
revealing all your source code, which makes scripting languages less inviting for commercial
applications.
Perl
NOTE Performance is a tricky matter. Although a well-optimized compiled program will
always outperform an interpreted program (at least on the initial execution of the program),
because of caching, the advanced subsequent execution of interpreted programs can easily
match that of the compiled programs. Additionally, because of hardware advances, the realtime
difference between the two is rapidly diminishing (though never quite reaching equality).
Interestingly, certain programming technologies such as Java and some .NET technologies are
both compiled and interpreted. This could lead one to assume that these would share the
faults of both compiled and interpreted languages such as added development complexity
and time and less than optimal performance. Although this may be true, they also gain a few
benefits such as portability and source code obfuscation. (That’s not to say that if a language
can be portable, it actually is.)
Perl (which stands for Practical Extraction and Report Language) is currently the leading interpreted
language used today (though Python and Ruby have been gaining on it over the past few
years). Perl, as its name seems to imply, was initially designed to work with large chunks of text:
to read in information and to parse it and/or manipulate it in meaningful ways. Thus, when the
World Wide Web came into being with all of its marked-up text, Perl, combined with CGI, was
uniquely suited to work with all of this data and manipulate it in fun, interesting, and useful
ways. As a web language, Perl’s popularity began to grow rapidly.
As a language, one of Perl’s greatest assets, and also one of its greatest weaknesses, is its fantastic
flexibility. It prides itself on providing multiple ways to solve any given task—Perl’s motto
is T.M.T.O.W.T.D.I. (“There’s More Then One Way To Do It”). In the hands of a skilled programmer,
this flexibility can unleash wonderful things, but it can also create a lot of unintelligible,
unmaintainable code (thus giving Perl the unflattering reputation as a “write-only” language).
The truth is that although Perl allows you to write some very ugly code, you can also write very
clean, understandable code in Perl. Most important, though, when you have a problem, Perl usually
can provide a way to solve it. For example, let’s say we wanted to simplify numbering lines
in source code (you know, because we’re writing a book, and sometimes it’s nice to refer to line
numbers). Rather than going through each code listing and manually entering numbers, we
could easy whip together the following script in Perl:
#!/usr/bin/perl -w
CHAPTER 19 EXTENDING THE POWER OF DARWIN 339
foreach my $file ( @ARGV ) {
my $n = 0;
open (OFILE, $file) || die "Sorry, $file can't be opened: $!";
open (NFILE, ">num_$file");