Computers and Society

David D. Thornburg, Associate Edtor

Metaphorical Computing

Every time we use a computer, we are working with metaphors. In some cases the metaphor is obvious, and in others it is not. A game, for example, might provide us with a model of a city through which we have to navigate without being caught by the bad guys. Rationally, we know there is no city or bad guys, but this metaphor lets us move beyond the computer to the application itself--the computer becomes the mirror of the mind's eye.

This aspect of the computer is what makes it so useful. Metaphors like desktops, menus, and windows can make computing appear more like "real" activities. Those who prefer command line interpreters to desktops are merely expressing a preference for one metaphor over another. None of this matters to the machine. As far as the computer is concerned, code is code and bytes are bytes.

High-level computer languages are programs and are therefore metaphors as well. As the noted computer scientist Edsger Dijkstra says in his book A Discipline of Programming: "There are two machines--the physical machine--the one that you pay for, that breaks down, that takes space on your desk. Then there is the abstract machine--defined by the functions the machine is to perform."

As programmers, we trust that the abstract machine is implemented in the physical machine. In fact, it might not be. For example, a program could accept 6502 machine language and convert it to run on a 68000 microprocessor. From the programmer's perspective, the computer is a 6502. The point here is that, even at the most basic level of programming, one cannot escape from metaphors.

Generations Of Languages

If computation is metaphorical at the machine level, it becomes even more so as we move to higher-level languages. In assembly language, for instance, the metaphor of the machine is often expanded to include instructions that the computer cannot execute directly. Programmers call these macros, or macro instructions. A macro that simulates a missing multiplication command greatly simplifies the programmer's task.

At the first two levels of computer language (machine and assembly), the metaphor pertains to the machine itself. At this level it is the program's purpose to instruct our computers. Once we move to high-level languages like BASIC, FORTRAN, COBOL, LISP, PROLOG, Forth, and Smalltalk, it becomes the computer's task to execute our programs. This may seem like a subtle distinction, but as we shall see, it is not.

I have come to believe that the major differences between various high-level languages are not to be found in their syntaxes, grammars, or vocabularies, but in their metaphors.

A Pascal programmer, for example, sees a program as a collection of procedures, each of which produces some effect. A LISP programmer sees a program as a collection of functions that output results in much the same manner as mathematical operations. A PROLOG programmer sees a program as a collection of assertions and rules that the computer can use as needed to respond to a query.

Now we can begin to see why it's so difficult to write major application programs. The programmer has the task of creating one metaphor out of another one. This is why multilingual programmers often spend some time deciding which language to use before writing any code.

The trick to making programming easy is to make the metaphor of the language match that of the application.

Construction Sets

Some languages do this quite well. The ease with which a user can create new pinball games with Pinball Construction Set is a result of the program's use of the same metaphor, whether a game is being constructed or played.

Other construction set languages (including Loderunner and any good spreadsheet program) have become immensely popular. Their popularity arises from ease of use, and this is a direct consequence of the consistency of the metaphor as one moves across the boundary from programming to executing a program.

While construction sets have great value, they also have a strong limitation. They are not general-purpose programming tools. One cannot build a word processor using Pinball Construction Set or a music program with Multiplan.

The closest we've come to general-purpose direct-manipulation languages is with products like Filevision, a Macintosh-based visual database program. I've used Filevision since 1984 as a tool for creating instructional software. But even Filevision (which was never intended to be a language) has its limitations.

The key to constructing a general-purpose direct-manipulation language is to find a "metametaphor"--a metaphor that encompasses all application metaphors. Does such a metaphor exist? This question is being asked by those of us who are exploring direct-manipulation programming. So far, the answer is not clear.

In the meantime, metaphors be with you.