by Terry Winograd
THE REACTIVE ENGINE PAPER BY TERRY WINOGRAD *** 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 *** NOTE: 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. *** WHY TIME-SHARING IS OBSOLETE: 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. *** GEDANKEN EXPERIMENT: 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? *** REACTIVE SYSTEMS: 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 *** CLAIM: The advantages of a reactive system over current interactive systems will be as large as the advantages of interactive over batch. *** NATURAL COMMUNICATION: 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 *** [image] *** 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. *** REMEMBERING AND DEDUCING: 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. *** PROGRAMMING AND DEBUGGING: 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. *** 18
