The Best of Creative Computing Volume 2 (published 1977)
The Reactive Engine Paper (XGP, ARPANET)
ranted about this elsewhere5 so will say no more here,
except to note that this is probably the most important
area where reactive systems will change our concept of
programming.
IS IT WORTH IT?
The same could be (has been and still is) asked about
interactive computing. Ask the programmer who has become
accustomed to an interactive debugging system and then has
to go back to octal (or hexadecimal) dumps. In the short
run (and we are always in the short run) this is a difficult
question, and I will take the escape given above - it is
certainly worth it if our research grants will support it.
In the long run I don't think there is any doubt. The costs
of processing, memory, etc. are going down and although
there may be ultimate limits, we are still far from them.
Anything which trades off increased processing for
increased ease of computer use by people will be eventually
justifiable on practical grounds. Twenty years from now
this question will be as outdated as it would be to ask now
whether it is really worth having the computer go to the
work oi accepting programs in symbolic form, since people
are perfectly capable of converting them to binary numbers
and entering them that way.
CAN IT BE DONE WITH CURRENT TECHNOLOGY?
Researchers at a number of places (including XEROX and
MIT-AI) are currently designing and building "personal
computers" which have a processing power far beyond
standard minis or "smart terminals." In fact many of the
ideas above are being implemented at Xerox. By connecting
these into a simple network with shared facilities for things
like specialized I-O (XGP, A-D and D-A, ARPANET, etc.)
and large file storage (allowing file sharing), these computers
could currently provide everything we get from a timesharing system, while
opening the way to all of the advantages
of reactive systems. At the moment, the cost per user (even
if they were commercially available - which they aren't)
would be significantly greater than an improved this-generation
time sharing system of the kind being planned at SAIL.
However the picture is not that clear if we look ahead the
3-5 years necessary to actually get systems running. Careful
thought needs to be given to realistically assessing what
hardware will (or could if we put effort into it) be available
by then, and how much it will really cost.
WHY SHOULD WE CARE?
This paper was circulated only partially because there is a
general interest in talking about systems. There are
particular reasons to think seriously about these issues now.
Al researchers (particularly John McCarthy) have always
been at the cutting edge of new systems ideas (like timesharing, list
processing, etc.). In this case I think we have
even more to offer, since many of the techniques which are
needed to build reactive systems are "AI techniques"
involving knowledge bases, deduction, etc. We have the
option of taking the viewpoint of "wiping the slate clean,"
thinking in terms of what we would really like to do with
the new technologies, rather than incrementally building
on the ideas and equipment now available. Even if the
appropriate personal computers were not available right
now, much of the design and debugging could be done on
current systems if we had a clear idea of what we expected
from the hardware.
PUNCH LINE: I believe that reactive systems are
"where it will be" a few years from now, and we
have the choice of leading or waiting to follow.
REFERENCES
1. Personal Computing by Alan Kay, Learning Group.
Xerox Palo Alto Research Center and A Personal Computer
for Children of All Ages by Alan Kay, ACM National
Conference, August 1975.
2. INTERLISP Reference Manual by Warren Teitelman,
Xerox Palo Alto Research Center.
3. The Treatment of Data Types in ELI by Ben Wegbreit,
Communications of the ACM 17, 5 May 1974.
4. COPILOT: A Multiple Process Approach to Interactive
Programming Systems by Daniel Carl Swinehart, Stanford
Artificial Intelligence Laboratory AIM 230.
5. Breaking the Complexity Barrier (again) by Terry
Winograd, ACM Sigplan Notices 10:1 January 1975.
