The year was 1995...
I had returned, some 6 months previously, to Apple Computer, after
being away for nearly two years. Unlike my previous stint at Apple,
this time my desktop machine did not run Unix. That was OK; I like
the Macintosh. This time, my job was called "Quality Lead", which
meant that I went to a lot of meetings. It did not mean I was writing
much code myself, however, and I was beginning to get bored.
Then the Code Coverage Metrics were dropped in my lap. The Metrics
were comprised of an enormous quantity of test and code coverage
data, produced by a program that usually ran on Unix. Thanks to our
contract with the vendor, the data was also being exported (dumped,
actually) in a format suitable for importing into a spreadsheet, such
as Microsoft Excel, on a Macintosh. All I had to do was massage the
raw data into something interesting and useful to present to the
weekly managers meetings.
There were many choices for how I could approach the task. Several
people suggested that I simply import the data into Excel, munge it
around by hand, and print the report. Every week. That idea, needless
to say, was abandoned without so much as a moment's serious
consideration on my part.
The second solution presented was that I use Excel's macro language
to subset and massage the data into something more usable. I had used
Excel's macro scripting capabilities before, at my previous
(between-Apples) job. I knew it could be done... I also knew that I
didn't want to do it.
If you've never worked with Excel macros on a Macintosh, you may not
readily understand. Excel macros can accomplish amazing things, but
they were not a "real" programming language in my eyes (the macros I
had used were in Excel 4; pre-Visual Basic). Language aside, Excel
macros are also Excel specific. They were not the type of experience
that I thought would look good on a resume'.
And, at least on a Macintosh, they run in real time. Almost, but not
quite, interactively, as you sit and watch. That is, while the macros
run, the machine is at their mercy. Having worked with Excel before
(on legacy files), I knew that Excel could do what I needed. But it
wasn't powerful enough, it wasn't flexible enough, and it couldn't
run in batch mode in the background while I did something else. So
that idea was rejected as well.
The third choice was Unix. I had been working with Unix since 1983. I
was experienced in awk and shell programming. I had an account on the
company Unix system. I could ftp the files over, run some scripts,
then ftp the results back to my desktop Macintosh. There, I could
stuff the information into spreadsheets suitable for printing and
distributing. It would have worked. But it wasn't the clean solution
I was really hoping for.
But maybe there was yet a fourth solution...
A friend had been telling me about Perl for 5 years or more. Given
that awk and shell did everything I needed (or so I thought :-), I
had been listening with only half an ear. But now, awk and shell
weren't readily available on my desktop. I had heard that there was a
Macintosh port of Perl. Learning Perl could do my resume no harm.
Perhaps Perl was the answer.
I downloaded MacPerl (version 4.1.8, based on Perl 4.036), bought
myself a copy of Programming Perl (the first edition) and
began to learn Perl. It was surprisingly easy (recall that I was
experienced already with shell, awk, and sed; I also knew C). Perl
was also surprisingly powerful. In short, Perl was getting the job
done.
In a fairly short time, I had a working script. Which, of course, I
began adding to. What additional statistics did we want? Which
additional data fields did we want to extract? How did we want the
data presented? With Perl, it was all possible.
I could even tell MacPerl to save the results in Microsoft Excel
format (with the appropriate Type and Creator IDs).
&MacPerl'SetFileInfo("XCEL", "TEXT", "$report");
MacPerl::SetFileInfo("XCEL", "TEXT", "$report");