Programming in the home of the future

Int. Z Man-Machine Studies (1980) 12, 341-365

Programming in the home of the future

BRUCE ANDERSON

Man-Machine Laboratory, Department of Electrical Engineering Science, University of Essex, Colchester C04 3SQ, England

(Received 8 July 1979, and in revised form 3 November I979)

For computers to be truly useful in the home of the future, they should be programmable by their users. The traditional idea of a program must be abandoned in favour of that of an environment of objects; programming becomes the act of augmenting this environment, and all interaction consists of evaluating expressions in it. Developments in language design and software engineering indicate how this very uniform interface might be possible, though this style of use imposes some difficult requirements. In the right such environment simple programming can yield useful results and lead to greater understanding both of the programming process and of the problem being approached. Such a powerful system could be used in three main areas: the local manipulation of data, including games and simulations; device control, which can be sophisticated and energy-conserving; and to communicate with other systems. This last possibility leads us to discuss several uses including mailing, teleconferencing, and access to databases of various kinds. Some social effects of the widespread availability of computer power are indicated.

1. Introduction

It is generally agreed that computer power will come to the home, and we can see this happening with the explosive growth in the number of home machines taking place now (Nelson, 1977). How can it be utilized and for what? What will the effects be? In this paper we take a long-range look at a set of possibilities, in a speculative manner. There are many pointers in current systems, and in current approaches, that lend support to the view presented, but certainly no proofs of its correctness, and indeed we point out problems that require research for solution. However it seems worthwhile, at least sometimes, to look ahead to what we might do eventually, rather than concentrate solely on what we can do next. Even so, we are able to add a good deal of flesh to the bones of the "Memex" personal computer system suggested (speculatively!) by Bush in the earliest days of computing (Bush, 1945); our approach is evolutionary in that it assumes that tasks that are currently difficult but possible will become easy, and that no revolutionary changes are needed.

2. Programming as the basis

The discussion here is based on the major premiss that programming will be a widespread activity and indeed we argue that this must be so for effective use of resources, that is if users are to become fluent users, or even to have that possibility. The fluency comes from source-level interaction with a real-time evaluator, such as currently exemplified by interactive languages such as Lisp (McCarthy etal., 1962), POP-2 (Burstall, Collins & Popplestone, 1971) or Smalltalk (Goldberg & Kay, 1976), so our

341

0020-7373/80/040341 + 25 $02.00/0 O 1980 Academic Press Inc. (London) Limited

342 B. ANDERSON

notion of programming, expanded below, is a wide one. This pattern of use does not correspond at all to current practice, where the number of computer programmers is much smaller than the number of computer users. We should make it clear that by computer user we do not mean the user of a machine containing a micro: the user of an automatic washing machine is no more a clock-and-solenoid user now than he will be a computer user in the future. We are talking about computer systems as explicit components of domestic hardware just as stereos or dishwashers are, and assume a powerful computer with many interfaces, a display system and so on. How is such a system to be used? How is the user to capture its undoubted power? The classic solution (i.e. adopted in the industry) is via applications packages, and this is the methodology currently adopted with home computers too.

2.1. CURRENT PROGRAMMING METHODOLOGY

2.1.1. The (DP) approach itself Applications packages attack single problems; you can buy a tax-form program, or a moon-landing simulation, or a model of a simple ecomomy. Also available are systems programs such as editors, assemblers and interpreters so that the user may write his own utilities or alter those he already has. The more sophisticated (sic) user may produce new systems programs, or improve old ones. The parallel with commercial data- processing is complete, and is not accidental but actively sought-after, perhaps because the home programmer feels he acquires status as he becomes a counterpart of his professional equivalent. I would like to argue that this approach is fundamentally inappropriate and if pursued would have a permanently and multiply stultifying effect on the exploitation of computers. What typically goes wrong?

2.1.2. Problems with the DP approach The general problem is that things which are conceptually simple, given the data and code (i.e. programs) to hand, often turn out to be difficult or at least tedious in practice. A slogan might be "one thousand and one things you can almost do with your computer" . The symptoms come under three somewhat orthogonal headings.

First is the lack of programmability. For example some editors have a search-and- replace command, but cannot do it for all instances, so that the command must be repeated manually until it fails. Often, in fact, to do some quite simple text manipulation one has to write a specific program and compile it! The disadvantages are dear , especially when the editor with the search-and-replace command obviously contains almost all the code that's needed! As a further example, suppose under TOPS-10 on the PDP-10 (DEC, 1974) we want to copy all the binary files more than two weeks old over to a backup directory. This involves calculating the date two weeks ago (essentially by hand); using the directory command to make a file of all the filenames of the form * .REL created since then; and using that file as an argument to the copying command. Thus:

D A Y T I M E 19-Jan-79:0000 ; getting date D I R E C T / S I N C E : 0 5 - J A N - 7 9 : 0 0 0 0 FOO = * .REL COPY [2552,3273] = @FOO

P R O G R A M M I N G IN TH E H O M E OF T H E F U T U R E 343

Similar examples of arbitrary complexity can be invented easily. They can be programmed only, if at all, by manipulating text files of filenames, as command files. The lack of programmability is often interpreted as lack of a powerful command language, or as a shortage of "features", but is a symptom of deeper problems.

Secondly, we usually find command-interface differences and incompatibilities. As new utilities are written, different commands are often needed to get similar effects. How many times have you tried to exit from a new program by trying QUIT, BYE, EXIT, END, FINISH and their seemingly infinite number of synonyms (and homonyms!) and abbreviations, with and without qualifying switches!

Thirdly, the programs don' t interface to each other, and few parts can be used, for example as subroutines, by other programs. Often the only way for them to cooperate is via intermediate files; and even if they can accept commands, as well as input, from files their lack of programmability (or the lack of facilities in the relevant job control language) makes this method very weak. As an example, suppose we wanted a letter-writing program which took a recipient's name, together with a piece of text, and produced a well laid-out letter with appropriate letterheading, addressing, salutation and text. We probably have an address-book program and a text-formatter, but can we use them? Can another program drive the former appropriately, for example dealing with the case where the address is not recorded there? Can a field for salutation (or formality level!) be added to the address? Can the formatter tell us how many lines or inches the text will take up so that we can decide on spacing and layout? In some cases nearly all this code has been written, yet in practice little of it can be used, at least in any direct way.

2.1.3. A bad framework It isn't (just) a question of poor design--it 's a poor framework. We can demonstrate this with respect to Unix (Ritchie & Thompson, 1974), the current darling of the small- system industry and a gleam in the eye of home programmers---for some the ultimate dream.

Unix's Shell provides for multiple processes and a uniform communication mechanism between them-- the byte or character stream (Thompson & Ritchie, 1974). For some text-processing this is appropriate, but too often a program must produce a linear representation of its results, only to have it fed to another program whose first job is to analyse this incoming stream and recreate the same structure! The lack of type information at this level means that typechecking cannot be done so that errors are hard to handle. For example, can a multi-byte integer (e.g. a L O N G in C) be written as several binary bytes and read correctly? It's safer to write it as digits and read it back with a short piece of code! It can require some ingenuity to design a series of textual manipulations to achieve a required structural manipulation, but the very fact that such solutions often exist (where they might not with even less powerful linking of processes) is seen as evidence of power, rather than the complexity of such solutions being seen as evidence of weakness! The flaw is clear; objects that programs manipulate cannot be represented properly at shell level i.e. at the level of the user's interaction.

2.2. A N O T H E R V I E W P O I N T

2.2.1. The notion of program The difficulty is caused by the notion of program, an idea supported from above by operating systems and from below by programming languages. The overriding yet in

344 13. ANDERSON

some sense implicit idea is that there are various different jobs to do and we should write (or at least use) different programs to do each of them. Thus the world is split into editors, sorters, line-numberers and so on. Of course it's recognized that sequences of such operations can usefully be joined together, and so we see the use of job control languages. These languages can become quite sophisticated, especially in a system where different ones can be provided, i.e. where they are not a part of the operating system itself. In one sense they are a powerful structuring tool, allowing programs to be joined together, but their power must be restricted because they cannot realistically provide the computational or representational power of all the languages whose programs they refer to. It's interesting to note here the schizophrenic notion of "efficiency" that is often introduced. All system programs are efficient, in their limited domain, and it's only the user who has to join them together who faces the resulting overall inefficiency both in ergonomic terms-- the joining is often hard and c lumsy-- and often in actual execution. This local efficiency allows systems programmers to maintain their feelings of superiority since it's the users who introduce the global inefficiency.

2.2.2. Augmenting an environment My suggestion is that a programming language is not for writing programs but for augmenting and manipulating environment of objects and operations. Thus the directory-manipulating example above should involve something much more like

forall F in MYDIR if F .EXT = ' R E L ' and A G E ( F ) < 14

then copy(F, BACKUPDIR) fi

endall

where we happen to use a Pascal-like notation. The difference here is not just syntactic but is fundamental. By operating on the directory structure itself and not a textual representation of it we both save inefficiencies due to conversion both ways and also get a handle on problems such as multiple simultaneous alterations. So we are proposing a unified single language system which supports incremental programming, and the notion of environment rather than of program. The emphasis is on manipulating procedures and data, joining them and modifying them, rather than on writing programs ab initio. This implies far more than the idea of a program or subroutine library, which stretches back to the beginning of programming (Wilkes, Wheeler & Gill, 1951), because they need not form any kind of consistent se t - - indeed the conventions for using them do in some sense define a language, but in a very cart-before-the-horse manner. Our philosophy is much more in line with Fitter (1979), to provide clear parts and a clear mechanism for the user to join them up.

2.2.3. Interacting via programming As a corollary we view the user's interaction with the system not as one of using programs, but one of writing them; that is to say the user is consciously dealing with the machine by getting it to evaluate expressions in its programming language. This evaluation is the same as the evaluation of expressions within programs; there is no distinguished "command language". Of course given the idea of virtual machine one

P R O G R A M M I N G IN T H E H O M E OF T H E F U T U R E 345

can view absolutely any interaction in this way--in that case we are saying precisely that the language of interaction should have the full power of a programming language, should in fact be the system's programming language, and should be designed and criticized in just that light. What objects can exist? Is there a good mechanism for repetition? How are conditionals written? How is naming done? These are just some of the questions that spring to mind (Landin, 1966; Reynolds, 1970; Popplestone, 1968). The practical effect is that stress is laid on the generation and manipulation of representations, on tools for extending the power of the language and environment without changing the language or introducing new "features". The programming language is the medium for communication in both directions. We take it as a right to be able to zero all elements of an array that are greater than 100, but how many operating system command languages allow one to delete all files over 100 bytes long? And we no more expect a special command for the former than we expect to find the latter at all! There are of course some examples of systems which go at least part way towards this ideal (Burstall et al., 1971; Hardy, 1979; Teitelman, 1978; Moon, 1974; Wegbreit et aL, 1972; Goldberg & Kay, 1976; Feurzeig et al., 1977) though oddly none are new developments, but they are flawed by weaknesses in the language chosen, or in their interface to the operating system. As a brief illustration, Lisp's lack of true record- structures means it cannot represent the user's file directory at all directly, though it can provide a structure that has components, unlike a string-based APL or Basic-like language. Usually, of course, such languages run under an (alien!) operating system so they cannot in any case provide the actual directory, but only some representation of some copy of it; an integrated system would allow the directory to be a user-accessible object, though this requires the language to be able to handle simultaneous access to objects by several processes. Interlisp (Teitelman, 1978) is the most widely-used system of the kind we are proposing, but it is marred by the enormous complexity it has acquired by years of incremental growth on a semantically narrow base. The system is so large and complex, and so entwined with the language interpreter, that it is not clear there what the basic language is; and in fact one must view the system as an agglomeration of several languages. It has the basic Lisp language, the evalquote language, the editor language, the top-level interaction language and the Algolish- syntax-allowing language (Teitelman, 1973) as well as the more subtle languages of filenames and system calls. This is not the place to discuss Interlisp in detail, but the brilliant display-oriented programmer's assistant (Teitelman, 1979) will serve as a final example. This facility is clearly an enormous aid to the control of the complexities of programming, yet many of the latter are an artefact of the system's primitive language base and incremental development.

Above we were critical of the Unix shell's representational power, but we should point out in its favour that it does at least have the notion that it is a language in that it allows composition of command expressions in various ways, and also the seeds of a notion of environment in that the command interpreter itself evaluates certain expressions (in particular filenames containing wild-cards) before passing them to the command in question. As an unfortunate postscript, however, the new version 7 shell (Bourne, 1978) has developed many of these ideas to produce a large and unwieldy system which, though more like a programming language, is more like a bad one!

We should emphasize that interacting via programming is at the most elementary level indistinguishable from using a package--it 's just that instead of issuing special

346 B. ANDERSON

commands, one might be executing procedures predefined in some environment. The major point is that one approach allows additions, enhancements and interfacing; the other works against it. Thus systems will be usable before programming skill is built up, though their full power will not be exploitable in that initial stage.

2.2.4. Design requirements

2.2.4.1. Programming language. What then are our design requirements? Recent developments in programming languages, though for classical program-construction oriented systems, show us the way. Emphasis on the software engineering process as a whole has led to techniques and language features which can be used in the way that we need. Firstly the problem of handling multiple processes has been attacked with some success, and could already provide, at least in a packaged way, sufficient power for the kinds of control problems to be found in the home (Hoare, 1978; Kahn & MacQueen, 1978). It remains a research question whether systems based on very large numbers of interacting processes will turn out to provide methods of attacking current processing problems (May, 1978; Hewitt & Smith, 1975), but we know that many problems do not positively require this type of solution. Secondly, and most importantly, the ideas of modularity, data-structure, information-hiding and so on which are needed for a structured approach to software development are now backed up by solid ideas on abstraction and encapsulation. The home user of the future will be programming "in the large" because he will deal with very many concepts and a great deal of data, and may want to relate any parts of it. Procedures don't contain enough to be good modules in a large system; it's too much to remember about them and also about the corresponding data-structures. One difficulty is that so many global names are used---or used up! The idea of abstract data-structure, combining structures and the routines that manipulate them, is a much more powerful one (Guttag, 1977), as exemplified particularly by Simula's classes (Dahl, Nygaard & Myrhaug, 1969), CLU's clusters (Liskov et al., 1977) and Alphard's forms (Wulf, London & Shaw, 1976). These are all more dynamic in style than the structures which led to ADA's module structure (Ichbiah et al., 1979); the style we are seeking is even more dynamic and might be caricatured as "Lisp meets Ada" (Jones, 1977). The advantages of Lisp-style interaction have been documented (Sandewall, 1977; Sandewall, 1978), though the lack of syntax and confusion of atom-as-object and atom-as-variable there are not essential (Anderson, 1976), as demonstrated in practice by the success of POP-2 (Burstall et al., 1971) and ECL (Wegbreit et al., 1972), which both have relatively conventional syntax, typed objects (though not typed variables), and a more regular semantics.

Our view, and a central thesis of this paper, is that the home user of the future will have a system which already contains many of the required basic abstractions, so that relatively little work will be needed to generate the ones required for the task in hand. Thus we have in mind that calendars and dates, bank statements and library catalogues will all be useable immediately, as well as more fundamental building blocks such as sets and other collections. The language will of course provide facilities for extension of abstractions, but alternatively new ones can be written using the given ones as a powerful guide: this has been an essential tool for developments in the Unix operating system, for example. Such abstractions differ vitally from utility packages in that they have no special interface syntax, and they can be explored and decomposed and parts

P R O G R A M M I N G I N T H E H O M E O F T H E F U T U R E 347

reused. Thus for example the address book abstraction would allow creation of address books, and manipulation of them by evaluation of expressions in the language itself. Of course this is just the framework for the answer to the software problem, not the answer itself. The right abstractions must be provided. Obviously at the lowest level we need sequences and sets and so on, but at higher levels creative design decisions must be made. Our belief is not just that this can be done (by experts), but that exposure to these designs can stimulate the user and educate him.

The address-book is an interesting test-case. It's very easy to enter the data, and the amount of it is quite manageable. In practice the problem is harder. An ordinary notebook is about the right size, portable, neat, and because of physical limitations garbage collection (if you use pencil!) and store-compaction (copying current data into a new book) take place somehow naturally. Out-of-date entries can be useful-- "what 's the name of the street where John used to live?"; "Tim's moved into Gordon's old place". And we can emphasize, annotate and repeat. Of course all these functions can be replicated if we want to use the computer merely as electric paper. But the question "who do I know that lives in Brighton" is not the same as "show me all the lines containing the string 'Brighton' ", and that extra structure, plus the other features such as control of archiving, are difficult to achieve.

There are of course many technical problems to be solved, not to say design issues to be resolved, before such languages become commonplace-- to what extent can command and programming modes be combined (Anderson, 1976), and should any syntactic extension be allowed (Standish, 1975), for example- -bu t these can be overcome by the time that suitable hardware becomes generally available. The problems are being attacked now, especially via the development of the Smalltalk (Ingalls, 1978), Extended-lisp (Weinreb & Moon, 1979)and POP-11 (Hardy, 1979)languages.

One of the most important requirements is imposed by the fact that interaction is generally to be viewed as programming. We will require that the language have explicit notations for the objects it can represent. Contrast this with, say, Pascal, whose general introduction and current popularity we regard with some horror. There is no notation in that language for anything but numbers and strings, so any interaction must be via some special-purpose driver routine which takes input in terms of these very low-level notions and constructs the required objects. Very often the writing of this routine is more difficult than writing the routine it feeds, especially as error-checking should be comprehensive. The evaluator is not available at run-time, so that Pascal expressions cannot be used to represent values; a "field" will have to contain "66" rather than "Fred.age" or "(Now--Fred.bir thday) .years" unless the user is to write a Pascal interpreter too! Again, consider just manipulating matrices of numbers- -we wish to read them in safely, and to alter individual elements, perhaps ones that have been mistyped. The driver for this is more complex than many of the routines that will handle the matrices themselves, and if it is to allow reference to matrices by name then it has to become a mini-language. Yet it is a new language, not Pascal, and we have entrusted its design and implementation to the individual user!

2.2.4.2. Software and system tools. The system in which the language is embedded, that is the tools which support the use of the language, wiU obviously be vital. Though the semantics of the language cannot depend on the use of a display, the pragmatics will lean on it heavily. We have talked about source-level systems, and for example we

348 B. ANDERSO~

require the corresponding editing facilities where the text under review is visible in its current state. But in editing objects we would want the idea to be of modifying structure which is reflected in changes in the text, rather than the other way ro u n d - - "ad d another case", "call normalize on the result of the addition". Some progress along these lines has been made in the design of editors for Lisp, such as the one for Interlisp (Teitelman, 1978). A program-constructing routine can aid the user by preventing syntax errors, for example by prompting for the " then" part after an "if", especially if the syntax of the language is engineered with this in mind (Eisenstadt, 1979; Sime, Arblaster & Green, 1977).

There is a close relation between teaching tools and debugging tools, so that for example the debugger's backtrace display or tracing facilities can be used to learn about the course of evaluation of working programs as well as to track down bugs in others. An interactive "caller" which calls a procedure on the user's behalf, prompting him for input or even turning the call into a form-filling activity are examples of powerful general-purpose tools that can be provided, and in a powerful enough computational formalism require no behind-the-scenes activity or special access to the system. They are procedures or abstractions or whatever, just like everything else. It's important that tools should be aids to the use or understanding of the system rather than special interfaces to it, as the latter restrict one's access and require the learning of yet another language, that of the interface.

As an example of the approach we've put forward, consider the description of the design of an interactive dialogue for scheduling TV advertisements described in Gaines & Facey (1975). The user chooses an action, such as booking, from a list, and is then prompted for the various data elements needed in turn. As the authors point out, the design of even such simple interactions is non-trivial, and rarely discussed in the literature. We would not (necessarily) want to alter that design, but to present it in an entirely different framework. There are two actions to be done each time round the main loop; select an action from a menu, and fill in the corresponding form. The "show menu" abstraction takes a set of actions and displays them for choosing from. This is a uniform mechanism--any set can be provided, and choosing is done in a consistent manner. Similarly "present and fill form" evaluates expressions at indicated points in order to fill in the components of the structure which is passed to it.

The uniformity and power gained via providing a menu abstraction and so on, rather than "designing a dialogue" is augmented by uniformity in facilities such as program interruption. It should be possible to interrupt the program and save the context while evaluating further expressions. This allows the user to find out how he is achieving the booking task, and to ask for help, without losing information. Similarly the open-ended nature of the approach allows him to augment the system, to define new commands or abbreviations or facilities.

Note that although we are discussing powerful systems that are beyond the current state of knowledge, we do not imply the need for any intelligence on the part of the system, i.e. we do not see any part of the problem of implementing such systems as an AI problem. We agree with Winograd (1979) in his emphasis on joining and altering software that already exists rather than always starting too far from our goal, but we disagree on this level of intelligence, and on the importance of declarative rather than procedural representations. Similarly the current vogue for constraint-stating languages and the corresponding constraint-solving interpreters (Borning, 1977; Steele


& Sussman, 1978) is a fascinating research area, but experience with previous such systems (Elcock et al., 1971; Fikes, 1970) leads us to doubt their importance for programming language design. It is absolutely vital for the programming system to present a clear and unambiguous model of evaluation; uncertainty (or incorrect certainty (Plum, 1977)) as to the outcome of a computation should never reflect on the structure of the evaluator.

2.2.4.3. Hardware. We are concerned here more with the conceptual and software structure of future systems than with their hardware realization, but what kind of machinery will be needed to support this style of programming and the uses to which it will be put? It's well-known that more hardware will be needed to develop these systems than to use them, and our guidance will come from that research and development effort. Rather than attempt to extrapolate from current systems we can use them as very definite minima. The Xerox PARC Alto (Thacker et al., 1979) is able to support the style of interaction we are proposing, but its 16-bit address space is clearly too small and its processor too slow. Users of larger machines find no difliculty in using 15 Mbytes of text storage. "A picture is worth a thousand words"--but an encoded TV picture occupying the same screen area as 1000 words (say 6 kbytes) takes up 100 kbytes (Dennis, 1979)! A high-resolution A4-size display is needed to compose A4-size texts, so a larger one is needed if we are to have other data displayed simultaneously. A book's pages can be flipped usefully at a character datarate of 2Mbaud, so some sophistication is needed in the display hardware. We expect users to be fluent, and that the keyboard will be the major input device because it is the only one allowing swift composition of complex machine-readable expressions. Research on pointing seems to indicate the superiority of the mouse over keyboard commands for that purpose (Card, English & Burr, 1978), but unfortunately the work reported used a special offset keypad that could not be touch-typed in the usual way, and the pointing software made almost no use of the information available in the display as an indexing structure. However soft keys and pointing devices could be provided too. Audio output provides an excellent modality orthogonal to the screen for many uses such as error messages, so a speech synthesizer would be included. Speech input is much more problematic but even current systems can provide a useful adjunct to tactile input (Turn, 1974). Hard-copy output is essential for taking to (the many) places where there are no computers, and for generating composite pieces of output larger than the display can handle.

The fact that the language system is incremental means that reasonable interaction can be maintained without the excessive peak loads on the hardware that conventional organizations can cause; think of the large number of Pascal recompilations done merely to change some constants (i.e. essentially to pass parameters!) and the resulting frustration while almost every operation of the previous compilation is duplicated.

2.2.5. Can ordinary people do it? One question that springs to mind immediately, usually as an objection, is whether this style of interaction, while undoubtedly powerful, is in fact beyond the majority of people, and could be carried out only by unusually able and motivated users after considerable training. Clearly motivation and training will be needed, but we expect the power of the system to be a strong motivating force. There is currently motivation to be

350 B. ANDERSON

able to read and write, and training is provided there too! Using reactive systems will occupy a good deal of the time of many people, as reading and writing do today. Of course the initial users will be middle-class professionals, as with most things, because they will be able to afford them at home and will have become familiar with the relevant ideas at work. Parker & Porat (1976) discusses the continuing changes in the number of people involved in the different basic categories of work; currently over half of the U.S. labour force is primarily engaged in information handling, and this percentage is increasing. At the most straightforward level there will be systems usable by issuing sequences of commands not unlike the simplest utilities of today, such as some text editors. Of course the user soon finds that certain sequences of commands are repeated, so programming concepts can be introduced as desired--viewing this interaction as programming implies that concatenation of actions to form new named actions is possible. There is no need to understand the underlying mechanisms, at least in any detail. Somehow the general concentration of (usable) computer power in the hands of computer specialists has led to a common belief that to use a facility one must understand its implementation; I suspect that almost the opposite is the truth! A broad but shallow knowledge of programming is not a paradox, and evidence from several sources supports this view. For example Clowes (1979) describes successful POP-2 programming in project work by liberal arts students; du Boulay & O'Shea (1978) the use of LOGO by schoolchildren; Goldberg & Kay (1977) some extremely sophisticated programs created, with help, by high-school children; Eisenstadt (1979) the augmentation of a cognitive psychology course on memory with a special programming language called SOLO. These systems have in common high-level interactive software, and the use of non-numerical domains of intrinsic interest to the user. Design principles emerging from this and related work (e.g. Green, 1977) form a basis for optimism. To a great extent the view that programming is for experts only has been put forward by those who have by poor systems and language design built artificial barriers of difficulty between man and machine.

2.2.6. Three models of data In rejecting a Unix-like (or even more primitive) system we have rejected the notion

that data is text or strings. Too much structure is implicit in algorithms if it cannot be explicit in data---each user essentially implements his own language. We can divide models of data roughly into three categories:

Model Representation Access Level Flexibility

text string matching low high database relations query language high low

programming data programs medium high

The discussion above indicates a programming i.e. data-structure orientation, but if we consider the kind of data that the home user will manipulate it seems that a data-base is a more appropriate model. It is a classic situation--large amounts of data to be organized but without complete prior knowledge of the way in which it is to be manipulated. This is indicated under "level"--does the data-representation have meaning independent of any specific use? Unfortunately ("flexibility") this is paid for,


as current database technology makes some kinds of representation very difficult, and even where databases are easy to use they may not be easy to design, which is the task the home user would face. The abstract data-structure approach has less independence of meaning but has sufficient flexibility to represent many more things straight- forwardly. Our intuition is that databases as such are ruled out as a general mechanism. The use of databases and some of the representation problems are discussed in more detail below.

3. How will it be used?

Given then that an appropriate software technology is to be available, how is this computing power going to be used? It's clearly going to be used at least for the local manipulation of data and for the controlling of devices in the home. So far our discussion does not assume the existence of more than one home system, though the economics of the production of its hardware and software dictate otherwise! Thus the third main area of use will involve communicating with other systems. The use of home systems will arise from wants rather than from pressing need; the expansion of possibilities they produce will make them desirable. Whether this or industrial and commercial potential will provide the spur for development remains to be seen. The systems we are describing will obviously not be restricted to the home; in particular we view the home of the future as a far more demanding application than the much- vaunted office-of-the-future as the tasks undertaken there are more varied, and home users will not put up with the poor interfaces that paid workers will!

3.1. M A N I P U L A T I N G L O C A L D A T A

Use for data-manipulation falls under several headings ranging from simple accounting to advanced (by current standards) simulation.

3. I. 1. "Business data "-processing One would of course expect to find the home equivalent of business data-processing, given that the home is in some sense a small business! Accounting could include checking bank statements and receipts, perhaps with automatic generation of financial predictions. Letter-writing can be greatly automated with text-editing, but we might hope to find that high-quality printing and display were available, then giving scope for designing one's own characters. Similarly a reactive system would allow easy experi- ments with layout, so helping to achieve attractive-looking communications. A gardening diary would contain much free text, but would contain some information in data-structure form so that questions could be asked- -"how long did the peas take to germinate last year?" , and the data thus used for planning and evaluation. Keeping this kind of data in the machine is no easy task, and requires careful design. Every use to which it will be put is not known beforehand, but overconstraining it by allowing no free text makes it unusable. So too does the opposite extreme of manipulating it only with a string-searching editor. The latter method might have, say, one "ent ry" per line, with delimiting characters for the "fields", and extract and process items with a string- matching expressions and possibly other utilities such as sorting programs. This should be viewed as essentially a private, and restricted, record-structure implementation. In particular, vital facilities for type-checking, error-detection and so on are likely to be

352 B. A N D E R S O N

missing, or at least inconsistent. It is yet another example of a seemingly simple approach (usually in a seemingly simple language) throwing vital design decisions into the lap of a usually unknowing user. Our approach hardly rules out design decisions, but should provide a better framework for taking them. Some components would be free text and some data-items; we might well need to refine the representation to move data from textual notes to other components after experience with the system, and would need this flexibility in the language. Recent work has emphasized treating tabular representations as such, and this may well provide the best interface in this kind of case (ICL, 1979; Smith, 1979).

Another simple illustration of the abundant (fascinating!) representational problems is that of U.K. telephone numbers. There is no uniform hierarchical notion of "area code" which is used as a prefix outside some area local to the number, but omitted within it. There is instead a local area outside which a single prefix code is indeed used, but within which various prefix codes are needed, essentially routing codes rather than naming ones, so that they depend on the location of the source of the call. Our database of phone numbers must enable us to ask "how do I call X from Y" for at least some range of Y's, yet even the representation of the Y's can be seen to be somewhat problematical! Our solution would definitely have to involve procedures more complex than table lookup, though the extent to which they require explicit knowledge of the BPO's network topology remains to be seen!

3.1.2. Playing games The system can be used for playing games--as many home systems are today. The possibilities are endless, especially for the truly creative role playing fantasy games which become possible when adequate computing resources are available. A consequence of our programming-oriented approach is that the augmentation of these games, and the inventing of new ones, become further areas of recreation. There are many .gther areas of entertainment----quiz programs, and even programming puzzles! Though real-time generation of complex images will probably remain relatively expensive there will obviously be some impact from low-cost video technology, which allows tens of thousands of frames to be stored. Ability to access these essentially randomly presents the challenge of systems for animation, which may well require the introduction of sophisticated multi-process software.

We have talked above of a single virtual machine, namely the single-language system, and of a multiplicity o f virtual machines, namely the groups of abstractions and commands used when attempting some task. To what extent can our, or any, language provide an appropriate environment for games where motor skills are required; simulations of pool or driving or tennis? Clearly a shot is not adequately described (as far as the user is concerned!) by position, angle and strength as typed-in integers. On the other hand, to what extent can the description of these via graphic or other input be considered as expressions of the programming language? The incorporation of these two styles remains a fascinating research problem. Some progress is indicated in Kay & Goldberg (1977) and Smith (1977).

3.1.3. Education Programs can be major tools for education, at the very least by helping to automate some routine parts of the process. Drill-and-practice is useful in arithmetic, quizzes are


useful in geography, and programs can check whether programming exercise solutions meet their specifications. There will be a great demand for knowledge about new technology, and we think at least some of this can come from appropriate computer programs. However, a distinction must be drawn between the use of the computer for routine work, and for access to resources, and its use as an intelligent tutor. The latter is still very much a subject of long-term research; development of such systems has been shown to be feasible for some limited domains (Brown, Burton & Bell, 1975), but still requires massive human and physical resources (O'Shea, 1978).

3.1.4. Simulation Simulation is another powerful tool that is readily made available with computer technology. Take the example of the gardening diary again and suppose we want to plan the layout of the garden and the sowing and planting sequence. A schedule can be made, and then actually executed as a simulation, using data from past experience for such things as growing time. The results can be used to refine the schedule, and so on. Many other planning tasks are amenable to this kind of treatment, and indeed this example illustrates an important part of our approach (Goldberg & Robson, 1978). We can use computers to augment our problem-solving ability, and the use of the home system is really aimed at this augmentation. It is no more appropriate (certainly in the current state of the art) for a program to actually plan the garden than it is for a program to plan a journey (Bobrow et al., 1977); but both of these tasks, and many others, can be aided by appropriate software.

3.2. D E V I C E C O N T R O L

By the time the hardware and software technology described here becomes available, the home will of course already be full of computers, in the sense that many household devices will contain microprocessors, as some do already. What then will be the impact of a powerful central system on device control?

3.2.1. Local control and co-operation It is certainly not to centralize the distributed computations already being carried out. The washing machine's program may well be capable of improvement, but such alterations are likely to be of interest only to the few, and to be prohibited by the manufacturer, or at least to invalidate the guarantee! Nor do we expect users to be hardware experts, so that devices will merely be provided with interfaces allowing control from the central machine analogous to control by switch or pushbutton today. The interface might be broadened, so that for example a spin-dry controlled as fast/slow and short / long might allow actual speed and time to be set, but anything more complex seems just unnecessary. The real advantages to be gained are in coordinated control of devices, not in individual enhancement, though of course the latter will happen anyway but using autonomous computation. We assume that interfaces and corresponding driving modules are readily available, but this will of course be realistic only if there is some standardization effort at hardware and low-level software levels. The only current standard is very low-level and does not allow concurrent real-time control ( IEEE, 1978). The simple use of peripherals depends on our language's ability to handle simultaneous processes and interrupts, an active area of research (Wirth,

354 B. ANDERSON

1977; Ichbiah et al., 1979). Simple co-operation between devices can be achieved; the stereo is turned down when the telephone is answered and the lights are turned down when we switch on the television. At the moment we have automatic oven timers; our future system will allow easier and more sophisticated control based on measurement of temperature and colour. In order to achieve some of the effects we require there will be a need for machine-detectable signals that are currently not provided, so that for example, the end of a piece of music or speech on a magnetic tape can be detected. Current devices attempt to do this from the audio track itself, with some complexity and little reliability (Arafeh & Efunshile, 1979). More interesting will be control of capture of broadcast material. Current VCR's, for example, are controlled by timeswitch alone. We don' t really want to record from 8 p.m. to 10 p .m. - -we want to record "that Mozart concert" , so we need some kind of signal that programs begin and end, and indeed some identification of the program. Of course we would like the commercials to be omitted from our recording--is the TV company likely to transmit that signal? Would our network be sufficiently real-time that such a signal would be available independently? Many issues are raised by the posssibility that on-line editing of the T V Times and Radio Times is all that is needed to capture the week's TV and radio programs.

3.2.2. More global considerations These examples of local co-operation between related devices are complemented by rather more global considerations. In the foreseeable future of relatively expensive energy supplies the accent will clearly be on devices that individually minimize energy use, but the sophisticated central control and measurement made possible by powerful computing resources will allow for sensible overall strategies of use. It may be best to run the dishwasher when the house is cold and occupied if the waste heat can be used. Marsh (1979) indicates some simple examples in this vein. Electricity prices could vary hourly (and perhaps daily) depending on the true cost of production, and algorithms local to the home could then minimize energy cost. At a less sophisticated level, energy consumption monitoring and display could lead to less wasteful patterns of use.

Control by timing devices can be replaced by control by need, allowing greater efficiency. This can include remote control via computer network, for example switch- ing on heating just long enough before one's (unpredictable) return rather than in time for one's earliest possible return.

3.3. COMMUNICATIONS

Remote control brings us to the topic of communication between these systems of the future. The only reasonable assumption we can make regarding the linking of home machines is that a universal high-bandwidth digital network will be available, enabling the joining of any two systems that wish to communicate. Such a common carrier for data does not yet exist in any country, though plans are clearly being made, and we leave to the future, and to the current literature, the myriad questions ranging from tariffs to protocols. There are of course current networks of many kinds, including those set up by hobbyists, but the net whose use bears most closely on the current discussion is the Arpanet , since many hosts act as (timeshared!) personal computers of some sophistication for users of some sophistication, and rapid data transfer between machines is simple and reliable. What kinds of usage can we envisage?

P R O G R A M M I N G IN T H E H O M E O F T H E F U T U R E 355

3.3.1. Interpersonal communication Firstly, let us consider interpersonal communication.

Computer networks can provide a mailing facility that is more convenient than the current media of telephone or of letter-writing. A message is composed using text- manipulation software and sent immediately to the intended recipient, who is notified as soon as it arrives but deals with it when convenient, thus achieving the immediacy of the phone with the permanence of the letter. The text is available for manipulation, and the use of other descriptors such as sender, source, time and subject allows for at least some automation whereby letters can be refused or forwarded. Because many more people can read and write a foreign language than can speak it fluently, informal communication across international boundaries could be greatly enhanced (Baran, 1977). Clearly problems arise here, from the naming of network users (Feinler, 1977) to restricting the sending of junk mail. The combination of a letter-writing program, a mailer, and a database of people's interests would surely be more than the Readers' Digest could resist, and more than the population could stand!

It's interesting that on the Arpanet one quickly gets to "know" people one is put in touch with, and a very informal level of contact is reached rather quickly. Also, communications can be very short and to the point in a way that would not be possible in other media- -a letter that short wouldn't be worth writing, and anyway it, or the corresponding phone-call, might well be considered rudely brief. Perhaps the fact that the Arpanet community is (still) a somewhat exclusive club explains these differences of interaction, rather than the medium being used, but it is certainly an area ripe for research. While there have been studies of networks used for sending messages in this way, they have been studies of systems specifically set up for this purpose and used for (pre-) defined goals (Engel etal., 1979); there is still a lack of investigation, really from a sociological point of view, of the uses of a network mailing system which is simply made available as a part of one's work (or home) environment to be used however one wishes. Lederberg (1978) discusses the importance of such informal contacts for the scientific community.

Teleconferencing is a more structured method of communication, which can vary in formality from merely agreeing to put files on some topic, together with comments on them, into some common file area, to a real-time system with complex display management and rules of interaction. Whether such a formal style of communication will appeal to the personal user, despite the obvious possible advantages, must remain to be seen and will certainly depend enormously on the design of such programs. This area has been the subject of numerous research projects, notably using Forum (Vallee, 1976); Hiltz & Turoff (1978) and Johansen, Vallee & Spangler (1979) cover the area in some detail.

3.3.2. Computational and software services There will obviously be providers of services connected to this net, as well as communicating home users. We can conveniently split the services into three classes: access to computational resources, provision of software, and provision of information. The first of these is the same as current timesharing bureaux--programs may be submitted for running, perhaps on unusual or very powerful hardware. The second is also straightforward, as software will obviously be for sale, to be transmitted to the purchaser or perhaps leasor or renter, via the network itself. Certification of this


potentially enormous volume of software is clearly a major issue, and it is not clear to what extent market forces will make conscientious suppliers band together to set standards and provide guarantees-- is some technical progress in the formal description and analysis of programs needed first? It's clearly essential to avoid the "almost what I want" syndrome of current conventional software; new techniques gives us the ability to avoid, or escape more readily from, this problem, but cannot guarantee its disap- pearance! Pressure must come from standards, and from consumers who are not just knowledgeable but have high expectations. (It's a commonplace that current low standards are partly due to customers' acceptance of them!)

Falling somewhere in between these categories are CAD services. We can expect designs personalized at least for size in many areas such as clothing, furniture, central heating, and small buildings such as sheds and home extensions. The opportunity for self-expression through making things like this will be greatly enhanced by access to such design tools.

3.3.3. Provision of data Provision of data to the home user is clearly destined to become a major industry, and we turn to this next.

There is currently a great deal of interest in the provision of information via the teletext services, of which the GPO's "Prestel" is the first (Stokes, 1978). For our purposes, however, the relevant pointers to the future do not come from such simple systems, but from less widely used but far more sophisticated ones. Prestel et al. are no model for the future, except in the most metaphorical of senses, because they lack so many of the features we expect and indeed require. Perhaps the most obvious is the fact that the information is provided in a purely textual form, so that we cannot perform local computation on it at all easily. Secondly, the system is not interactive, thus restricting greatly the kind of query that can be made, and thus the kind of information that can be made available. Thirdly, the bandwidth to the user is very low, a difficulty exacerbated by the small screen size. As an example we can take the interrogation of a railway timetable to plan a journey.

Given this small page size and low bandwidth, clearly the whole page of a real timetable cannot be displayed, so the system must compress the data. Some data is redundant, e.g. the precise times of stops at intermediate stations, but probably the number of such stops isn't, nor an indication of whether it is a through train or not. Time of departure may matter less than journey time, so we may well want to select on that basis; we are already talking of interaction beyond Prestel's capabilities. Even imagin- ing it improved with a larger display, the extra problems introduced when planning a journey involving several trains and stations would clearly involve a lot of local processing, i.e. copying data from the screen with pencil and paper! This example has assumed that the enquirer wishes to plan his own journey----clearly an alternative, given only the extension to alphanumeric input, is for a helpful program to plan the journey, which will require the output only of a few departure times. The difficulty here is that planning a journey is subject to so many constraints, both explicit and implicit, that writing a program to do it properly is currently a long-term research goal (see, e.g. Bobrow et al., 1977); it is a typical example of a task where given the right facilities computer-mediated or even computer-aided planning is ideal, but where planning BY computer is impossible. To have the latter foisted on one because of lack of facilities for

P R O G R A M M I N G I N T H E H O M E O F T H E F U T U R E 357

the interaction needed for the former is an all- too-common phenomenon, and is bound to alienate and frustrate potential users. Narrow bandwidth means the program must be intelligent--it 's easier to increase the bandwidth than to implement intelligence!

Far more relevant are database systems, which are really very different. Firstly, they contain information rather than just text, and this can be sent in machine-readable form to the local machine. They are interactive, allowing the small relevant subsets of their large store of data to be extracted, and we are assuming that our net has a bandwidth high enough for us to be able to extract the data we need. Our difficulties are not solved so easily, however; it is merely that access to database-like structures provide at least a framework for the free and useful flow of information. Several vital technical questions remain. Can the data we wish to access be represented in a database? Can the questions we wish to ask be expressed, and will the system compute the answers correctly? How do we manipulate locally information selected and received from the remote site? First the representation and query issues. A database is currently taken to be a uniform representational system for passive data of a rather uniform kind, and we assume an associated query language of some kind for accessing the data. Relational systems together with the relational calculus are typical of this kind of system. The uniformity aspect is vi ta l - - the rationale for the introduction of databases was as a unifying scheme whereby information was no longer contained in a multiplicity of files of varying format, with idiosyncratic access and all the problems of redundancy, incompatibility and so on. The very fact that databases were even possible was however a reflection to a great extent of the kind of data that was kept, and the kind of queries made. Typically this data was in the form of record structures with small fixed numbers of components and relatively easily stored in files. The examples in books and papers on database use give it all away with their large tables of employees, employee numbers, departments and salaries, and their queries about average salaries and maximum scales. How different this is from our apparently mundane railway-timetable example!

Putting aside the displayed format with its interesting and effective symbolism as a (vital but orthogonal) syntactic issue, several semantic features stand out: non-uni- f o r m i t y - n o t all trains from A to B stop at C; linking of t ra ins--some connect with, or become, others; exceptions by t ra in--some do not run on certain dates; exceptions by s top--some stops are timed differently or omitted on some occasions. The first of these features says that the matrix of arrival and departure times, indexed by station and train, is a sparse one, so that the corresponding relation will have many null entries. A set or list-like structure seems more appropriate for this, and also for the annotated links between columns that indicates connections between trains. The use of exceptions is probably the most powerful and least tractable mechanism here though. The point containing the time "18:06" also contains the link to the note "Saturdays 5 minutes later"! So far the only uniform mechanisms proposed for handling such exceptional cases are in AI-or iented programming languages (Sussman, Winograd & Charniak, 1970; Davis & King, 1975).

So we see that the state of the representational art in database design is such that much of what we want to access cannot easily be stored that way. One would not expect a database to store matrices efficiently, or to solve the linear equations they describe! Even for the large domain of data that can in fact be represented in a database, the problem remains of extracting it, i.e. the query language or other human interface. The methodology for home computing put forward above indicated the use locally of a

3 5 8 B. ANDERSON

programming approach based on abstract data-structures, whereas access to databases by non-professional users currently stresses non-algorithmic query statement and a very high order of data-representation independence. It is certainly true that casual users find access via relational algebra or relational calculus quite difficult, and a good deal of work has been done in interfaces more suitable for them (Cuff, 1979). Our approach assumes the almost inevitable development of some programming ability by users ,but anyway does not rule out the use of powerful supporting software, so that we might, for example, regard Query-by-Example (Zloof, 1975) as a graphic aid to the construction of queries in the relational calculus. Many queries CAN be broken down into a reasonable sequence of simple steps, and the extent to which this approach succeeds will depend both on the complexity of queries to be made and the power of the abstractions provided. The key point is that simple queries should be simple to program. This area is one where graphical display of data and relationships will be extremely helpful; the amalgamation of programming and database ideas is currently an interesting research area (see, e.g. Atkinson, Martin & Jordan, 1978), and the work on table-manipulating languages in the word-processing field mentioned above is also very relevant. Perhaps because of pressing practical problems of actually using and improv- ing current databases there has however been relatively little investigation of the limits of current ideas as far as representational adequacy goes; (Kent, 1978) is a counter- example.

Even given representational ability, the sheer quantity of information will cause naming problems; conventional file structures, whether of the computer or office variety, will surely be inadequate. We will need local (file, group, folder) organizations, and also more global ones, but in the absence of a single conceptual scheme, i.e. given that some items must fall under several headings, we must use the computer 's ability to scan rapidly; we can no more expect the user to remember the name of every procedure or abstraction than we can expect it to fit a single slot in a hierarchy. Naming problems exist on current systems--at a well-known site on the Arpanet with 1600 Mbytes of online private storage, but a primitive filing systems of a few directories per user, and online access to the index of a complete tape archive of every file created in the last ten years, files age and become lost; they can be known to exist but be impractical to find.

We have concentrated up to now, perhaps unduly, on computation over structured information, rather than reading or retrieval of textual data. This latter, however, may well constitute one of the main uses of our network system. To what extent can access to literature be automated? Information retrieval systems such as those currently available (Hall, 1977; Salton, 1975) would be quite suitable for use over the network. The high bandwidth means that interactive search can be carried out effectively because it is easily augmented by scanning. Browsing is also facilitated; the display's quality means that full-text systems will be desirable, and indeed the size of the potential user base makes indices to whole texts, rather than just to abstracts, a more economic pro- position. We would expect to see an expansion in the role of "information brokers" (Ferguson, 1977) as a counterpart to current library staff. The interface to IR systems will, like others, be programmable so that the user can use local software to set up regular searches, or even to compare different services automatically. As well as programmable access to data we need access to programmable data, that is we want to retrieve and manipulate non-textual objects from the information store. This is currently an area of growth in the IR field: Boyle et al. (1977) describe a system for


accessing the atomic potential literature and then calculating with retrieved potential functions; one can even retrieve a corresponding subroutine for use in one's own program. There seems to be some convergence between IR and DB methods; (Teskey, 1979) describes the use of a full-text general-purpose system as a library loans database by using an appropriate simple front-end processor. Luedke, Kovacs & Fried (1977) survey systems which are sources of numeric data; most have only primitive facilities for its manipulation. The expansion we see requires the availability of software, as mentioned above, and of all kinds of data from maps to music. FINDIT (Weyer & Kay, 1976) presents, though does not work out in detail, a synthesis between conventional IR ideas and Smalltalk's Simula-like class mechanism; each class of data can have its own matching and retrieval methods.

3.3.4. Interchange methodology How are we to achieve the interchange of data between local and remote sites assumed above? Transmission involves the linearization of perhaps complex structures, and their reconstruction at the receiving end. For natural-language and program source text the problem is not difficult, though clearly even here standards are required. For data the solution is subsumed by the requirement on the programming language being used that it provide an external representation, i.e. a textual notation, for data and even for partial computations. This requirement is non-trivial, especially when sharing of structure takes place. While we are optimistic enough to believe that the right kind of languages will be in use in single-language systems, we cannot expect them all to be the same, and indeed would not wish progress in language design to be stifled by such uniformity. By at least allowing compatible external formats our programming system again provides a mechanism for a solution but not the solution itself. It is interesting to note that the Arpanet protocols for data interchange (principally the File Transfer Protocol) are extremely low-level, and only relatively recently have higher-level protocols (speech, graphics) become more widely used. Of course any two consenting adult users can set up a private protocol and then achieve interchange with it via a low-level protocol, and this can work (and has worked well) when the number of possible interactions is low. The volume and variety of traffic on the "net of the future" indicates the need for a more thoroughgoing approach to the transmission of abstractions.

4. Social effects

What will be the social effects of the envisaged widely-available computer power and simple high-bandwidth connections? This is not the place to attempt to make such (fascinating!) predictions in detail but it seems worthwhile to outline some of the new possibilities raised. Wise (1976) indicates that the predictions of the effects of technology are significantly less accurate than predictions of technological changes.

4,1. C R E A T I N G N E W I N F O R M A T I O N

The basic change is the enhanced ability of individuals to manipulate and disseminate information, so the widening of possibilities is greatest for those in the information- handling industries. The possibility of working at home is commonly mentioned in the literature, though whether one wants to do that is too often ignored (Nilles, 1976). It


seems more likely that working habits will evolve as systems and networks do, so that initially perhaps overtime or weekend work is done away from the office, then occasional suitable days and so on. This is the pattern that has emerged so far at several institutes where home facilities have been made available. Obvious too is the possibility for widely-separated individuals to form common-interest groups. What about the effects on the publishing industry? Traditionally books are expensive to produce and to market, as shown by the small percentage of the selling price that accrues to the author. It's clear that software to allow an individual, or a small group, to produce a book is essentially with us now, and will become widely available. The book-as-text can be distributed easily via the network, and not much improvement in printing technology is needed for the book-as-object to be created easily in small numbers too. The small numbers is the key here, that a book does not have to sell in large volumes to be worth producing. Such books would still have to be advertised and reviewed, and perhaps those industries would undergo the biggest change of all. Similar principles apply and it would be well worthwhile to run a reliable book-recommending agency; local experts become global. What will be the difference between a library and a bookshop? Despite some predictions, books won' t die out; paper cups haven't entirely displaced porcelain. There will clearly be a place for books as practical transportable objects as well as objects of beauty in their own right--i t will be a very long time before the quality of display output exceeds high-quality colour printing. The evolution of media merely separates (or perhaps clarifies the relation between) form and function.

We speak of books, and by implication journals too, and they will obviously continue to exist, but new media create new possibilities. A magazine need not be just a series of pages. As just a simple example it could be a closure of the text with a reading program so that you pay more if you skip the ads, but get paid if you don't just read them, but actually make an order! The puzzle page can be interactive too, so the notion of a magazine becomes a new medium perhaps closer to current teaching machines, but able to go well beyond it.

4.2. NEW ACCESS TO OLD INFORMATION

So far we have talked about the possibilities for access to information that is in some sense created rather than collected, but there will be enormous possibilities for manipulation of data such as Government statistics of all kinds. Currently such data is often available very much later than its time of collection, and only in processed and textual form. There are clearly complexity barriers preventing cheap dissemination in any other way, and these barriers can of course be extremely convenient for those in possession of the raw data. In the future however, with high-speed connection and, at least at some level, standardization of representation, possibilities are raised of consumer groups obtaining the data, doing their own analysis, and readily publishing it. Implicit restriction of access to data by mere inherent complexity will have to be replaced by freedom of access--or by explicit restriction.

Of course not all dissemination of ideas is, or has to be, in the form of books or papers or articles. The broadsheet of earlier times can be reintroduced; so we could expect a literal explosion in the number of short documents of opinion, on topics from economic policy to the quality of different washing machines. Where in the system would these documents reside, and at what cost to whom? How can they be retrieved? If sufficient bandwidth is available then we can retrieve not just highly encoded material such as

P R O G R A M M I N G IN T H E H O M E O F T H E F U T U R E 361

text, diagrams and programs, but also pictures and music. McCarthy (1973) has proposed that one could retrieve musical recordings of one's choice over the network, for a f ee - -a National Juke Box.

4.3. WHERE WILL THE PROGRAMMERS COME FROM?

The methodology above, not without evidence but perhaps controversially, assumes a level of ability (or, rather, of effectiveness) at programming that can only partly be explained or provided by the increase in quality of the tools provided over those currently available. Where will all these programmers come from? The answer must lie in the use of the computer as part of the educational system. This is not the place to make a detailed study of CAI, CAL and the many disputes that have taken place, and are taking place, about the role of mechanized systems in teaching, so we will confine ourselves to a few points. Firstly it is clear that programs and other materials can be provided on the system so that programming can be learned without constant access to a human teacher. These materials include exercises and grading programs as well as examples. The system itself is a source of knowledge, since it can be explored to any level required. Of course the system cannot answer (directly!) many questions, but experience shows that many can indeed be answered by peers in the learning process who will be reachable via the network, and access to " teachers" (or "teaching assistants") can be provided in the same way. This makes their use of time very effective, so that the distinction between teacher and doer can be blurred. I see programming in this future as gardening is today- -a subject about which many people have knowledge at different levels, where knowledge resources are many and varied, and accessed in different ways. Nobody feels they should attend a lecture-course on gardening before digging the first spadeful, nor do they visit the nearest Horticultural Institute whenever things go wrong!

Having indicated where new programmers will come from, we need to say where current, and future, professionals will go to! The sort of expansion in computing that we are envisaging implies no redundancies. Very skilled work is needed for the design and implementation of the systems we have been discussing; for developing teaching methods; and of course for working on larger and harder problems than home use presents.

4.4. EDUCATION IN GENERAL

What about education in general? There are basically two approaches to the use of the computer here. One holds that it is just a tool, and could for example be used to enhance courses such as the Open University now offers by access to interactive programs such as simulations and to further teaching materials, and by allowing easier access to tutors. The other approach which is less common is that the computer itself is a powerful metaphor, and that understanding a subject can be greatly enhanced by writing programs related to it. Papert 's work teaching geometry via computer graphics is a well-known example (Papert, 1972), as is the Edinburgh work with mathematics students (Howe, O'Shea & Plane, 1979), but elsewhere others report success via students' attempts to program far more complex topics such as industrial wage- bargaining (Clowes, 1979). Now clearly to write a program that is generally illuminating on such a topic is even in the envisaged state-of-the-art a very major project; the point of the exercises described is the personal illumination that comes from the thinking in

362 13. ANDERSON

terms of the computational metaphor that is forced on one when writing such programs. Problem-solving via programming requires the generation of representations, dividing the task into parts that are clear, and interact clearly. Each part should be meaningful, representing a useful abstraction in its own right. The program must of course be machine-executable, but the extra requirement of human intelligibility not only makes solution easier, but enhances the users capacity to think fluently in computational terms. It is this kind of thinking that is transferable to other, non-programming, domains. The educational and motivational spin-off from such attempts should not be underestimated.

5. Conclusion

Until now computers have been a conservative force; through their use many cumber- some procedures such as that of banking have been able to continue beyond the complexity or size that can be handled by manual methods. Current home computing merely supports and reinforces this image. Perhaps people in general have been helped by this kind of application, but we see a future where computers are a much more positive and direct life-enhancing force. Overall our philosophy is optimistic--we see a set-up in which the power of the individual is enormously enhanced, but where the ability to share is enormously enhanced as well. The evolution of such systems will be a major force for social change in times to come.

My ideas have been influenced by very many people, both directly by discussions and indirectly by environments they have created. I am particularly indebted to Richard Bornat, Max Clowes, Brian Gaines, Carl Hewitt and John McCarthy.

References

ANDERSON, D. B. (1976). A brief critique of Lisp. Proceedings of AISB Summer Conference 1976, University of Edinburgh.

ARAFEH, H. & EFUNSHILE, J. (1979). Microprocessor-controlled cueing of audio signals. Project Report. University of Essex, Department of Electrical Engineering Science.

ATKINSON, M., MARTIN, J. & JORDAN, M. (1978). A uniform, modular structure for databases and programs. Internal Report CSR-33-78. University of Edinburgh, Department of Computer Science.

BARAN, P. (1977). Some perspectives on networks--past, present and future. In GILCHRIST, B., Ed., Proceedings of IFIP Conference 1977 459-464.

BOBROW, D. G., KAPLAN, R. M., NORMAN, D. A., THOMPSON, H. & WINOGRAD, T. (1977). GUS, a frame driven dialog system. Artificial Intelligence, 8, 155-173.

BORNING, A. (1977). THINGLAB--an object-oriented system for building simulations using constraints. Proceedings of the Fifth IJCAI (Cambridge, MA), pp. 497-498.

BOURNE S. (1978). The UNIX Shell. Bell System Technical Journal, 57, 1971-1990. BOYLE, J., MCDONOUGH, W. R., O'HARA, H. & SMITH, F. J. (1977). An on-line numerical

data system. Program, 11, 35-46. BROWN, J. S., BURTON, R. R. & BELL, A. G. (1975). Sophie: a step towards creating a reactive

learning environment. International Journal of Man-Machine Studies, 7, 675--696. BURSTALL, R. M., COLLINS, J. S. & POPPLESTONE, R. J. (1971). Programming in POP-2.

Edinburgh: Edinburgh University Press. BUSH, V. (1945). As we may think. Atlantic Monthly, 176(1), 101-108.

PROGRAMMING IN THE HOME OF THE FUTURE 363

CARD, S. K., ENGLISH, W. K. & BURR, B. J. (1978). Evaluation of mouse, rate-controlled isometric joystick, step keys and text keys for text selection on a CRT. Ergonomics, 21, 601-613.

CLOWES, M. B. (1979). Computers and Thought--an experiment in teaching about computing. University of Sussex Cognitive Studies Programme.

CUFF, R. N. (1979). Database query systems for the casual user. M.Sc. thesis. Department of Electrical Engineering Science, University of Essex.

DAHL, O.-J., NYGAARD, K. & MYRHAUG, B. (1969). The Simula-67 Common Base Language. Pub S-22, Oslo: Norwegian Computing Centre.

DAVIS, R. & KING, J. (1975). An overview of production systems. Memo AIM-271. Stanford Artificial Intelligence Lab.

DEC (1974). TOPS-IO Monitor Manual. Digital Equipment Corporation. DENNIS, T. J. (1979). Personal communication. DU BOULAY, n. & O'SI-IEA, T. (1978). Seeing the works: a strategy for teaching interactive

programming. Working Paper 28. University of Edinburgh, Department of Artificial Intelligence.

EISENSTADT, M. (1979). A friendly AI software environment for psychology students. AISB Quarterly, No. 34, 11-12.

ELCOCK, E. W., FOSTER, J. M., GRAY, P. M. D., MCGREGOR, J. J. & MURRAY, A. M. (1971). ABSET--a programming language based on sets; motivation and examples. In MELTZER. B. & MICHIE, D. Eds, Machine Intelligence, 6, 467--490. Edinburgh: Edinburgh University Press.

ENGEL, G. H., GROPPUSO, J., LOWENSTEIN, R. A. & TRAUB, W. G. (1979). An office communications system. IBM Systems Journal, 18, 402-431.

FEINLER, E. J. (1977). The identification data base in a networking environment. In Proceedings of the National Telecommunications Conference 1977 21:3.1-21:3.5, IEEE Com- munications Society, Boston, MA.

FERGUSON, P. (1977). Chronicles of an information company. On-line Review, 1, 39-42. FEURZEIG, W., LUKAS, G. & LUKAS, J. D. (1977). The LOGO Language: LearningMathe-

matics Through Programming. Portsmouth, New Hampshire: Entelek. FIKES, R. E. (1970). Ref-Arf: a system for solving problems stated as procedures. Artificial

Intelligence, 1, 27-120. FITFER, M. (1979). Towards more "natural" interactive systems. International Journal of

Man-Machine Studies 11, 339-350. GAINES, B. R. & FACEY, P. W. (1975). Some experience in interactive system development and

application. Proceedings of the IEEE, 63, 894-911. GOLDBERG, m. & KAY, m. (1976). Smalltalk-72 Instruction Manual. Xerox Palo Alto Research

Center. GOLDBERG, A. & KAY, A. (1977). Teaching smalltalk. Memo SSL 77-2. Xerox Palo Alto

Research Center. GOLDBERG, A. & ROBSON, D. (1978). A metaphor for user interface design. Xerox Paio Alto

Research Center. GREEN, T. R. G. (1977). Conditional program statements and their comprehensibility to

professional programmers. Journal of Occupational Psychology, 40, 93-109. GUTYAG, J. (1977). Abstract data types and the development of data structures. Com-

munications of the A CM, 20, 396-404. HALL, J. L. (1977). On-line Information Retrieval Sourcebook. London: Aslib. HARDY, S. (1979). POP-It Reference Manual. University of Sussex Cognitive Studies Pro-

gramme. HEWITr, C. & SMITH, B. (1975). A Plasma Primer. MIT Artificial Intelligence Lab. HILTZ, S. R. & TUROFF, M. (1978). The Network Nation. Reading, Mass.: Addison-Wesley. HOARE, C. A. R. (1978). Communicating sequential processes. Communications of the ACM,

21, 666-677. HOWE, J. A. M., O'SHEA, T. & PLANE, F. (1979). Teaching mathematics through Logo

programming; an evaluation study. Working Paper 115. University of Edinburgh, Depart- ment of Artificial Intelligence.

364 B. ANDERSON

ICHBIAH, J. D., BARNES, J. G. P., HELIARD, J. C., KRIEG-BRUECKNER, B., ROUBINE, O. & WICHMANN, B. m. (1979). Rationale for the design of the Ada language. SlGPLAN Notices, 14(6).

ICL (1979). 7700 Information Processing System Users' Manual. International Computers Ltd. IEEE (1978). IEEE Standard 488-1978. New York: Institute of Electrical and Electronic

Engineers. INGALLS, D. (1978). The Smalltalk-76 programming system: design and implementation.

Proceedings of the Fifth Annual A CM Symposium on Principles of Programming Languages, pp. 9-16.

JOHANSEN, R., VALLEE, J. t~ SPANGLER, K. (1979). Electronic Meetings. Reading, Mass.: Addison-Wesley.

JONES, A. K. (1977). The narrowing gap between language systems and operating systems. In GILCHRIST, B., Ed., Proceedings of the IFIP Conference 1977 869-873.

KAHN, G. & MACQUEEN, D. (1978). Coroutines and networks of parallel processes. University of Edinburgh, Department of Artificial Intelligence.

KAY, A. & GOLDBERG, A. (1977). Personal dynamic media. IEEE Computer, 10(3), 31-40. KENT, W. (1978). Data and Reality. Amsterdam: North-Holland. LANDIN, P. J. (1966). The next 700 programming languages. Communications of the ACM, 9,

157-166. LEDERBERG, J. (1978). Digital communications and the conduct of science: the new literacy.

Proceedings of the IEEE, 66, 1314-1319. LISKOV, B., SNYDER, A., ATKINSON, R. & SCHAFFERT, C. (1977). Abstraction mechanisms

in CLU. Communications of the ACM, 20, 564-576. LUEDKE,, J. A., KOVACS, G. J. & FRIED, J. B. (1977). Numeric data bases and systems. Annual

Review of Information Science and Technology, 12, 119-181. MARSH, P. (1979). The house of the future is in Phoenix. New Scientist, 84, (1176), 114. MAY, D. (1978). EPL Programming Manual. University of Warwick, Department of Computer

Science. MCCARTHY, J. (1973). Is there anything left to invent? Stanford Artificial Intelligence Project. MCCARTHY, J., ABRAHAMS, P. W., EDWARDS, D. J., HART, T. P. & LEVIN, M. I. (1962).

LISP 1.5 Programmer's Manual. Cambridge: MIT Press. MOON, D. A. (1974). MacLisp Reference Manual MIT Artificial Intelligence Lab. NELSON, T. (1977). The Home Computer Revolution. South Bend: Distributors. NILLES, J. M. et aL (1976). The Telecommunications-Transportation Trade-off: Options for

Tomorrow. New York: Wiley. O'SHEA, T. (1978). Artificial Intelligence and computer based education, Computer Education

30, 25-28. PAPERT, S. (1972). Teaching children thinking. Programmed Learning and Educational Tech-

nology, 9(5), 245-255. PARKER, E. B. & PORAT, M. (1976). Background report on social implications of

computer/telecommunications systems. In Proceedings of the Conference on Computer/Telecommunications Policy. OECD informatics studies 11, 87-129. Paris: OECD.

PLUM, T. (1977). Fooling the user of a programming language. Software Practice and Experience, 7, 215-221.

POPPLESTONE, R. J. (1968). The design philosophy of POP-2. In MICHIE, D., Ed., Machine Intelligence, 3, 393-402. Edinburgh: Edinburgh University Press.

REYNOLDS, J. (1970). Gedanken--a simple typeless language based on the principles of completeness and the reference concept. Communications of the ACM, 13, 308-319.

RITCHIE, D. M. & THOMPSON, K. (1974). The UNIX time-sharing system. Communications of the ACM, 17, 365-375.

SALTON, G. (1975). Dynamic Information and Library Processing. Englewood Cliffs, N.J.: Prentice-Hall.

SANDEWALL, E. (1977). Some observations on conceptual programming. In ELCOCK, E. W. & MICHIE, D. Eds, Machine Intelligence, 8, 223-265. New York: John Wiley.

SANDEWALL, E. (1978). Programming in an interactive environment: the Lisp experience. Computer Surveys, 10, 35-71.

PROGRAMMING IN THE HOME OF THE FUTURE 365

SIME, M. E., ARBLASTER, A. T. & GREEN, T. R. G. (1977). Structuring the programmer's task. Journal of Occupational Psychology, $0, 205-216.

SMITH, D. C. (1977). Pygmalion, A Computer Program to Model and Stimulate Creative Thought. Basel & Stuttgart: Birkhauser.

SMITH, D. C. (1979). Personal communication. STANDISH, T. A. (1975). Extensibility in programming language design. Proceedings of the

AFIPS 1975 NCC, 44, 287-290. STEELE, G. L. & SUSSMAN, G. J. (1978). Constraints. Memo 502. MIT Artificial Intelligence

Lab. STOKES, m. W. (1978). Viewdata: A Public Information Utility. London: Input Two-Nine. SUSSMAN, G., WINOGRAD, T. & CHARNIAK, E. (1970). Microplanner reference manual.

Memo 230. MIT Artificial Intelligence Lab. TEITELMAN, W. (1973). CLISP---conversational Lisp. In Proceedings of the Third IJCAL

Stanford, California. TEITELMAN, W. (1978). Interlisp Reference Manual. Xerox Palo Alto Research Center. TEITELMAN, W. (1979). A display oriented programmer's assistant. International Journal of

Man-Machine Studies, 11, 157-187. TESKEY, F. N. (1979). STATUS and integrated information systems. In Proceedings of the 7th

Cran]ield International Conference. Xerox Palo Alto Research Center. THACKER, C. P., MCCREIGHT, E. M., LAMPSON, B. W., SPROULL, R. F. & BOGGS, D. R.

(1979). Alto: a personal computer. To appear in SIEWOREK, BELL & NEWELL, Eds, Computer Structures: Readings and Examples (2nd edition).

THOMPSON, K. & RITCHIE, D. M. (1974). Unix Programmer's Manual --Fifth Edition. Bell Laboratories.

TURN, R. (1974). Speech as a man-machine communication channel. Proceedings oftheAFIPS 1974 NCC, 43, 139-143.

VALLEE, J. (1976). The FORUM project; network conferencing and its future applications. Computer Networks, 1, 39-52.

WEGBREIT, B., BROSGOL, B., HOLLOWAY, G., PRENNER, C. & SPITZEN, J. (1972). ECL programmer's manual. Memo 21-72. Harvard University Center for Research in Computer Technology.

WEINREB, D. & MOON, D. (1979). Lisp Machine Manual. MIT Artificial Intelligence Lab. WEYER, S. & KAY, A. (1976). Information Manipulation on a Personal Computer. Xerox Palo

Alto Research Center. WILKES, M. V., WHEELER, D. J. & GILL, S. (1951). The Preparation of Programs for an

Electronic Digital Computer. Reading, Mass.: Addison-Wesley. WINOGRAD, T. (1979). Beyond programming languages. Communications of the ACM, 22,

391--401. WIRTH, N. (1977). Modula: a language for modular multiprogramming. Software Practice and

Experience, 7, 3-35. WISE, G. (1976). The accuracy of technological forecasts 1890-1940. Futures, 8, 411-419. WULF, W. A., LONDON, R. L. & SHAW, M. (1976). Abstraction and verification in Alphard:

introduction to language and methodology. University of Southern California ISI. ZLOOF, M. M. (1975). Query-by-Example. In Proceedings of the AFIPS 1975 NCC, 44,

431--438.

Documents

Programming in the home of the future