8. ADDRESSES
8.1. KEYNOTE SPEECH, BY A.J. PERLIS
Why has this meeting been scheduled?
Why have we agreed to participate?
I believe it is because we recognize that a practical problem of considerable difficulty and importance has arisen: The successful design, production and maintenance of useful software systems. The importance is obvious and the more so since we see only greater growth in demands and requirements in the future. The consequences of poor performance, poor design, instability and mismatching of promise and performance are not going to be limited to the computing fraternity, or even their nearest neighbors, but will affect considerable sections of our society whose ability to forgive is inversely proportional to their ignorance of the difficulties we face. The source of difficulty is distributed through the whole problem, easy to identify, and yet its cure is hard to pinpoint so that systematic improvement can be gotten.
Our problem has arisen from a change of scale which we do not yet know how to reduce to alphabetic proportions. Furthermore we must assume that additional magnification of goal will take place without necessarily being preceded by the emergence of a satisfactory theory or an organized production of tools that will permit work and costs to fall on growth curves which lie significantly below those which now exist. For example, we can see coming the need for systems which permit cooperation, e.g., between engineering and management information. Not only must we know how to build special purpose systems but how to combine them into larger ones.
We work with software knowing that the design of a software system always seems to make some complex functions available with ease and others, seemingly little different, available only in a cock-eyed way. Such shortcomings in design are probably inevitable even in the very best systems and are simply consequences of the inevitable disparity between the degree of connectivity of human thought processes and those of a programmed system. It is also true that every system creates, through the very pattern of its usage, a set of anticipated bottlenecks. To avoid these bottlenecks users of systems learn to accommodate. Every software system thus imposes an etiquette on users, as every system which is created is itself a recognition of an existing etiquette.
Software is intimately tied to language even though it obviously involves more. Computer languages are processed by software and language is used to command the processing. This causes a problem and suggests a cure. The problem arises out of the relative ease with which out of our involvement with language we propose innovation. The cure is that the same ease of innovation can be focused on improvements which will help in the creation of systems. Programming tools are created — or innovated — to harness the power of an already existing hardware system. The specialization of these tools is of major importance in making the computer available to a wide range of genius for application to a wide range of purpose. A major function of these tools is the utilization of equivalences, i.e., a program which is easily written is shown equivalent to one which is easily executed by the computer. Another major function of the tools is the management of data with their appropriate operations and language inventions. Here the essential innovations are those which force sequencing to be handled implicitly and selectively by explicit command, e.g., as in the use of patterns, keys, generators, etc. the establishment of equivalences and the management of data are often accomplished by the invention of virtual computers which themselves are tools existing only as expressions in language.
To my mind the natural way to explore and manage the software problem is through the design of virtual machines — and all that the concept of machines implies — the establishment of relevant states, their transformations, the design of communication channels, the nature of and magnitude of storages, the natural sets of operations, the I/O problem, etc. We have before us many examples which have, in more restricted areas of programming, worked amazingly well. The symbol manipulating languages — IPL and LISP to name two — have been so organized that the problems coded in them have yielded codes organized as complexes of machines, each one of which is much like those from which it was constructed. Indeed certain operations in the primitive machine carry over to all levels in these machine cascades because they are regarded as indigenous to the class of tasks handled.