A computer-aided design system is too often characterized or glorified by its size and its repertoire of operations. A zoo of design services frequently provides the designer with the illusion of generality through sheer quantity of specific routines. In Steven Coons’s original Outline of the Requirements for a Computer-Aided Design System (1963), the danger of exhibiting a false generality has been well marked. As long as the designer never calls for a capacity that is not rigidly embedded in the machine, the system will be successful. However, since it is not feasible to predefine and to pinpoint all plausible operations and design activities, it follows that a successful design partner might be composed of one intelligent and adaptable service rather than a group of special-purpose services.
The principle is simple and, in computer-aided design history, old. A well-nourished platoon of specific design operations expects a status quo and excludes a methodological evolution and self-improvement. As a consequence, so-called problem-oriented languages have been developed in an attempt to avoid this stagnation by providing each user, after a brief learning period, with the potential of creating his own tailor-made utilities.
A problem-oriented language is a high-level computer language whose formulation and implementation assume a specific discipline or set of disciplines. Such a language provides the equivalent of a set of nouns, verbs, and phrases. A user can easily learn them because of their simplicity and relevance to his profession. For a civil-engineer user, basic operations, like calculating bending moments or shear forces, might appear as verbs and be combined with declarations; for example, TYPE PLANE TRUSS YZ/LOADING LIST ‘TRUS-UNI’/DETERMINATE ANALYSIS (Logcher, 1967). With such commands, the user can implement his own algorithm for determining the behavior of a structure.
But two things are wrong. First, we have a condition where each designer is creating his own library of services out of the problem-oriented language. Once created, note that these operations are no less rigid and specific than the predefined package of design commodities. Even though the routines are user chosen and user made, they might be less effective than if created by someone (or a machine) versed in the computer sciences, with the full potential of lower-level languages available to him. Second, when using a problem-oriented language, the user-made repertoire of operations is largely determined by the language itself and the user’s understanding of it rather than by the nature of the design problem itself. The appearance of particular commands in the language and the absence of others completely prejudices both the choice of problem and the method of implementation. In other words, a problem-oriented language gives the same illusion of generality as the rigid regiment of services. The common failure is a misunderstanding of the difference (which is not a semantic difference) between flexibility and adaptability.
The omission is evolution. A dialogue must be evolutionary; a mechanical partner must be evolutionary and hence adaptable. An adaptable machine is a generalized mechanism that at any instant can transform itself (in response to a change in context) to appear as a special-purpose machine. By sampling its environment, an adaptable machine could freely move from a state of universality to a state of single-mindedness.
No adaptable machine exists today. However, we can (and should) discuss the environment that such machines might sample in order to transform themselves. So far we have presented a duet—designer and machine—in which the machine’s “image” of the real world is solely through one human partner. The designer’s personal prejudices and distortions of the real world would be planted, consciously or subconsciously, in the machine. In such a closed system the machine could easily develop into a “design patsy” or “yes-man.” The machine would not challenge goals; it would only be prepared to mimic the communicative manner and methodology of its one user. In this situation the designer could embed his preconceived answers, and, accordingly, a noncreative, complacent partnership would be formed through the lack of a challenging environment.
Beyond the one-architect-one-machine dialogue, the milieu of an adaptable machine must embody two further contacts with the real world. First, an adaptable machine (and thus an architecture machine) must receive direct sensory information from the real world. It must see, hear, and read, and it must take walks in the garden. Information should pass into the machine through observation channels that are direct rather than undergo the mutations of transfer from the real world to designer’s sensors to designer’s brain to designer’s effectors to machine’s sensors. The designer does not completely control data that are collected in a manner that avoids the consequent losses of information at each transfer point. Such data bolster, once again, the machine’s capacity to challenge.
A great deal of research is being conducted in the quest for mechanical sensors. Probably the first to be incorporated with an architecture machine will be a seeing machine; this will be briefly described in a subsequent chapter. At first, machines with eyes will observe simple physical models; eventually, they will observe real environments.
A second tie to the real world would be the capability of overviewing designers, their definitions, activities, and methods. Surveillance of other designers’ procedures again nourishes the machine’s ability to challenge. For example, the machine could alert its partner to the practices of other designers. (They provide greater direct outdoor access in high-density residential areas.) This response would allow the designer either to correct himself or to reinforce his own and his machine’s convictions further. At the same time, each designer would be able to tune into controversy by dialing an anonymity or an opposing view that would discount his own whims and pet details. A designer would be able to subject himself and his machine to an objective scrutiny that would consist of (1) an evolutionary mapping of popular desires, (2) a statistical overlay of solution patterns, and (3) the images of architects he esteems.
This overviewing would be achieved through a parent machine, not by machines in residence. The same central machine that provides the big bursts of computational power would be host to all the local issues resulting from many separate architecture machines. The parent machine can be a referee, an information source, a communication medium, a historian, as well as simply a giant calculating mechanism. The parent machine would store all building codes, Sweets Catalog, Graphics Standards, and all the geographic and demographic data of the world. (The reader should note that the constitution and design of such a machine is not the prime concern of this book. Our main concern here is the machine in residence.)
An architecture machine that could observe existing environments in the real world and design behaviors from the parent would furnish the architect with both unsolicited knowledge and unsolicited problems. Someday machines will go to libraries to read and learn and laugh and will drive about cities to experience and to observe the world. Such mechanical partners must badger us to respond to relevant information, as defined by evolution and by context, that would otherwise be overlooked.
Machines that poll information from many designers and inhabitants, directly view the real world, and have a congenial dialogue with one specific designer are architecture machines. They hint at being intelligent machines.