THE VETERAN NEOPHYTE

LISP, COLOR ICONS, AND LAYERS

DAVE JOHNSON

I recently started learning Lisp, in order to write a color icon editor for a project in ACOTSM (that's Apple Classroom of Tomorrow). The people behind ACOT are creating an environment in which kids can build and explore simulated ecologies, and I wanted to help, but didn't know Lisp well enough to be of much use. A color icon editor was needed, and it seemed like a straightforward and painless little project to cut my Lisp teeth on. Hah.

I did learn lots of Lisp, but I spent a disproportionate amount of time learning the low-level system interface in Macintosh Allegro Common Lisp (MCL) and wrestling Color QuickDraw to the ground. For you CopyBits fans, did you know that CopyBits always assumes that the destination PixMap is on the current GDevice? I guess I already knew this--it's documented all over the place--but the implications never affected me before. I needed to convert a 4-bit PixMap to 8 bits, so hey, let's use CopyBits, right? Wrong. The colors got munged every time, because color mapping kicked in and the source's color table didn't match the GDevice's. For the gory details, see Technical Note #277, especially the section on color mapping. If you like CopyBits, you'lllove this tech note.

I was curious what others thought of Lisp, so I asked around a little. Here are some of the responses I got:

Functional languages are cool if you have good libraries, but all those parentheses are a pain in the ass.
-- Bryan "Beaker" Ressler, C programmer.

It's the shortest distance between conception and realization.
-- Matthew MacLaurin, self-admitted Lisp junkie.

I hate it.
-- Neil Day, who was forced to write the Tower of Hanoi iteratively in an introductory Lisp course.

It's a great productivity tool, and Common Lisp provides a rich (though perhaps Byzantine) programming environment.
--Gregg Williams, technical writer and sometime Lisper.

(expectant look)
-- Natty, my dog.

There are several immediately apparent things about Lisp that are foreign to people used to C or Pascal. Data typing is nonexistent unless you want it: Any variable can hold any type of data at any time. Functions can be data, too, and can be passed around all over the place. Everything is cozily wrapped in parentheses many levels deep (after a while, this is somehow comforting). Context is all important and omnipresent. Changes can be immediately tried out, so forprototyping (and for those of us who thrive on immediate gratification) it's a joy to work in. For those lacking in discipline, Lisp can help to create a real mess (of course, any language can do that for you, it's just easier in Lisp). Because it is so forgiving, it encourages my own built-in "middle-out" design

strategy, which in the long run isn't terribly efficient, although lots of fun. With a little self-control, of course, this problem would go away (left as an exercise for the reader).

Writing Lisp code that is QuickDraw intensive is kind of a pain at first. MCL provides great libraries for basic QuickDraw tasks, but if you want to get fancy, you have to do it yourself. For the icon editor, I needed lots of little utility routines to do stuff like find a particular color's pixel value in the color table, add a color to a color table, copy a cicn, change the depth of a cicn, build new cicns from scratch. Nearly half my code consists of these little utilities. They'd be needed regardless of the language, I guess, but writing them in Lisp required me to learn the low-level system interface much more thoroughly than I originally intended. This made me grumble a little, but after I'd gotten over the initial syntactical hump, low-level access became transparent and largely effortless.

The other half of the code was much Lispier. I used the built-in object system (Object Lisp, since I was using MCL 1.3.2. Now, in MCL version 2.0, it's the Common Lisp Object System, or CLOS), and I found that it successfully isolated me from most of the grungy system details like events and window handling (that's what it's supposed to do, right?). I haven't done a lot of object programming, so I can't make incisive comparisons with other object systems, but I liked it.

The sort of layered, threaded structure of Lisp, and the continual "level switching" I had to do during development, got me thinking about how the machine is getting progressively more distant from the software I write. It seems that I write software to live on top of other software, not software to live on a machine. Object programming is a kind of layer creation, in that a well- designed object hides lots of details from the user of the object. MacApp is a layer (a thick one), HyperCard is also a layer (a really thick one), the Mac ® Toolbox is a layer, and so on.

More and more, programmers need to be comfortable stuffed between these layers. Here's the hard truth: YOU NO LONGER HAVE TOTAL CONTROL OF THE MACHINE. Once upon a time, in the dim and distant past, programmers had absolute power over every aspect of the computer. There wasn't even any such thing as a user! A programmer was God in a monotheistic universe. Now there are all sorts of software smoke screens between your code and the machine itself. You are no longer God; at best, you are a minor demigod in charge of shoes, or something. A long time ago I read a discussion of Macintosh programming, and one person compared it to sitting in a dark closet by yourself, and occasionally answering a note that is passed under the door from the outside. I think that's exaggerating a little, but the point is valid. You no longer need to know everything that's going on in the house; you can just be responsible for your own room. At least, that's the idea . . .

One persistent problem is that you have to depend on the reliability of the other code. When my icon editor was almost done, I found a memory leak. Two tiny handles were left on the heap after closing the editor. It took me almost a week (and some expert help) to track it down to a bug in the MCL object system. Obviously, this diluted the benefits gained by using the system.

Overall, though, I really do think that this division of labor, this layering, is a good thing. It lets people find the niche they like best, and ignore much of the rest if they want to. Often it is an incredible time-saver to learn to use others' code rather than learning to do what they did from scratch. Ideally, the layers will insulate you completely from irrelevant detail, and allow you to focus on your task. We're not there yet, but someday, maybe, you can actually stop inventing the wheel.