The Best of Creative Computing Volume 2 (published 1977)

Page 18 << PREVIOUS >> NEXT Jump to page:
Go to contents Go to thumbnails
This book is also available for the Kindle

The Reactive Engine Paper (arguments for the personal computer, why time-sharing is obsolete, reactive systems, natural communication, editing, programming and debugging)
by Terry Winograd

graphic of page

This paper, written in October of 1974, originally appeared as a file on the
computer at the Artificial Intelligence Laboratory at Stanford University where
Terry Winograd is currently leading courses in computer science, linguistics,
and the social implications of computing. At the time of writing the people at
SAIL were discussing how to design their new timesharing system. Another file
was also maintained on the system in which comments, suggestions and objections
could be stored. It is an argument for personal computing - not an essay, but a
sort of cybernated commentary.

-Marc Le Brun

This is written in an attempt to provoke discussion, so it may overstate,
exaggerate, etc. It is written from the viewpoint of the Ivory (silicon?) tower,
so the issue is "What is possible?", not "What is now practical?" After all,
working at the AI lab you would never realize that there are still people in the
world (even at Stanford!!) who talk to computers by cutting little holes in
pieces of cardboard.


Time-sharing is obsolete because it is based on the assumption that a person
interacting with a computer large enough to do serious work cannot make good use
of its computing power except during a fraction of the time.


Imagine that by a decree of God (or ARPA or whoever) we were only allowed to run
one user at a time on the PDP-10. All the systems efforts would be directed to
making each person's time on the computer as profitable as possible. What kind
of system would you organize?


I will borrow a term from Alan Kay (from whom I have also absorbed many of these
ideas) to contrast our current "interactive" system with an imagined "reactive"
system. A reactive system contains a full-scale processor whose only job is to
cater to a single user. It can therefore afford to do relatively large amounts
of processing when he or she is doing the simplest of tasks, like editing or
giving monitor commands. It can maintain complex reactive graphic displays in
real time (e.g. the multiple windows in the current SMALLTALK system).1

The advantages of a reactive system over current interactive systems will be as
large as the advantages of interactive over batch.


One of the main advantages of a reactive system is that it can afford to do
extensive processing to figure out what the user wants to do, based on both what
he or she says and what the current context is. This is the main feature of
natural language as a communication system - it is designed (evolved) with the
assumption that the hearer will always make use of context and a shared base of
knowledge in his interpretation. People are much more efficient at communicating
in this style, regardless of whether it is in actual "natural language" or in
some artificial language. There are lots of bits and pieces of this in current
systems - everything from default file extensions to command completion to the
rather extensive set of facilities (like spelling correction) in INTERLlSP.2 On
current interactive systems there is a strong tendency to avoid these because
they involve running a higher-level program to interpret inputs. With 
a reactive system, the bottleneck is the user's typing speed (although we could
even imagine some sort of simple voice inputs if we pushed this idea far
enough), so we can afford to do lots of processing.


Often the problem isn't that we want to specify a command in a way which needs a
smart processor to understand what it is, but in a way which takes a smart
processor to do it. If we were talking at the command level to a program with
even limited deductive capabilities (the kinds now put into robotics programs)
it would free us from much of the tedium of converting our desires into "machine
code." Why shouldn't we be able to say in some language "put the current who
display in a file" and let the system worry about the details of just what needs
to be run.

The whole range of things like UNDO, REDO, etc., which are creeping into
languages like INTERLISP could be extended to cover every aspect of our
communication with the computer - it could remember the context of what we have
been doing, and make the necessary deductions to do rather sophisticated things
(e.g., redoing some sequence of actions, but tailoring it to apply to a
different kind of data object).

EDITING: Maxim: People Never Edit Character Strings.

Whenever I am editing, I am editing a document, a message, a program, or some
other structure about which I know much more than the simple sequence of
characters. The reactive system should always be dealing with my editing in this
way. Formatting systems for documents should be interactive and incremental -
what I see on my screen should always be what I would see on the Xerox Graphics
Printer when I put it out. This includes fonts, justification, diagram
placement, etc. etc. Of course the program should be able to reconfigure and
modify this in a whole variety of ways, but I should always be working with a
document, not a source file (or even a screen editor!) When I put in a new word
or line, things should move to make room for it. Things like spelling-checking
could be done incrementally, looking up each word as it is typed in, then when I
ask for it, interactively pointing out those not in the dictionary (e.g. by
flashing them) and letting me make changes. For programs, the editor should be
part of an integrated programming and debugging system (as in INTERLISP), not a
separate program at all.


We have glimpses of integrated systems in SMALLTALK, INTERLISP, ECL3 and
Swinehart's thesis4 describing a SAIL-based system. Often these are forced into
horrible compromises by the fact that they are walking the line between wanting
the user to have the full power a program can offer at each step of the way,
while having to run them on time-sharing systems which are based on the
assumption that you really only want to process part of the time. They fall far
short of putting in the kind of integrated knowledge-base and deductive programs
which would really allow the system to act as a programming assistant. They do
not make full use of the possibilities for incremental compiling (coupled with
the editor) which can give the user the feeling of always working with an
interpreted system, while actually having the efficiency of careful compiling.
They are only beginning to make use of the kind of graphic interactions which
can greatly broaden the programmer program bandwidth. I have
Reprinted with permission of the author.  Copyright 1975 by the CoEvolution
Quarterly, Sausalito, CA 94965.


Page 18 << PREVIOUS >> NEXT Jump to page:
Go to contents Go to thumbnails
This book is also available for the Kindle