“Computerized” operations are too often misnamed “computer-aided.” The computerized/computer-aided distinction is too often confused with, or solely embodied in, the mode of machine usage.
The traditional (for the past 20 years) mode of computer usage, “batch processing,” entails a computation center to which a user delivers a “program” (a deck of cards, magnetic tape, paper tape) to be “run.” Then several hours or days later the user returns to receive his “output.” More recently, a new mode, “timesharing,” allows terminals (usually teletypes) in the office or at home. The terminals are connected to a large central machine (and thus interconnected with each other) by standard telephone lines. This system of remote and multiple machine access permits many physically separated users to share one large machine at the same time. The rapid swapping of users’ programs in and out of the central machine provides each user with the illusion of a dedicated machine and permits him continual use of his terminal. This mode of operation is a form of “on-line” usage.
It is commonly suggested that by furnishing a time-sharing system the on-line nature of the interaction in itself is a dialogue and transforms computerized procedures into computer-aided ones. This is simply not true. For example, let us suppose you desire the average apartment-to-parking-space distance for some design project. In a batch-processing mode (assuming the program exists) you supply as data the description of your design, and the average distance returns hours later, indeed a computerized procedure. On the other hand, in a realtime environment you have a teletype terminal, the project description resides in the machine, and you simply type in the apartment-to-parking-distance command. But just because the answer comes back in three seconds rather than three days, computerized does not become computer-aided. It simply becomes more convenient “computerizedness.” Computer-aidedness demands a dialogue; events cannot be merely a fast-time manifestation of causes and effects.
On-line communication therefore is not a sufficient (though necessary) condition for a computer-aided environment. Computer-aided design requires at least three additional features: (1) mutual interruptability for man and for machine, (2) local and dedicated computing power within the terminal, and (3) a machine intelligence.
Interruptability gives a dimension of interaction that allows the process, as well as the product, to be manipulated. In a computer-aided system, the machine may interrupt the user and present the unsolicited information, for example, that the cost of his low-income housing project is fifty-eight dollars per square foot. The architect might welcome the remark, ignore it, or take offense and request that such interludes of finance be restricted. However, regardless of the designer’s response, the apparent high cost might have overlooked substantial indirect savings not accounted for in the original estimating routine. In this case the designer could tamper with the estimating procedure and incorporate hitherto neglected parameters.
Unfortunately, the present time-sharing philosophy fosters a cause-and-effect conversation. Time-sharing assumes that a designer’s explicit manipulations will occupy between one and ten percent of any sitting; the remaining time represents his deliberations and distractions. Each user’s moments of contemplation are in effect another user’s instants of computation. A designer can interrupt his own program, but a routine cannot easily interrupt its partner in thought. In order to leave the computational utility available for other users, each routine resides in the machine only when explicitly called into service by its particular user. In other words, the routine (the user’s machine) can listen but cannot interrupt.
To retain the assets of time-sharing, avoid the anathema of batch-processing, and acquire mutual interruptability, we adjust the allocation of computing power. We transfer some of the information-processing power and transfer a certain manipulative and storage capacity to the terminal that was originally a teletype transmission and reception device. This semiautonomous terminal (possibly portable) is a small computer that would be a “machine in residence.” An architecture machine would be such a machine. The designer would speak directly to this satellite machine. In turn, this small, remote computer would interactively converse with larger parent machines. (Sending work out to a central mechanism would be automatic and exclusive of the designer; the recourse would be for reasons of speed or memory or information or all three.)
The machine at the location of the designer would undergo the personalization. It would be composed of additive and subtractive pieces of hardware as determined by the discipline of its partner. This local aggregation of parts would perform the dialoguing, the evolving, and the interrupting. Observe that the interrupting and the reinterrupting would depend on the nature of the designer’s activities, on the context of his efforts. Through familiarity with a specific designer’s idiosyncrasies, the appropriateness of the machine’s interruptions would be suitably reinforced by context—the inception of an intelligent act.
Leon Groisser at home in his garden.
The author at home.
Computers at home are already being used in an informal manner.
Architecture students using the time-sharing system CP/CMS. Since 1965, all M.I.T. architecture students have been required to take at least one semester of computer programming as a prerequisite to the Bachelor of Architecture degree. Most of them have had the good fortune to learn on a time-sharing system. The advantage is obvious: on a console, a student can take high risks and can play. This is what learning is all about.
A mechanical partner, as we have suggested, must have intelligence. Customarily, computer-aided design studies and intelligent automata studies have been antipodal efforts “between mechanically extended man and artificial intelligence” (Licklider, 1960). On the one hand, in the context of computer-aided design we are told to render unto each their respective design functions and talents: man thinks and the machine calculates. On the other hand, in the context of automata studies we are told that “Anything you can do, a machine can do better.”
The two outlooks are not necessarily contradictory. For the present discussion there is a real issue whether machine intelligence can be independent of human intelligence. In computer-aided design only the combination of mechanical amplification and mechanical imitation will validate the dialogue. The dialogue will evolve an intelligence, this intelligence will stimulate a more profound dialogue, which in turn will promote further intelligence, and so on. Furthermore, the concurrence of “extended designer” and “artificial designer” will force a design redundancy and an overlapping of tasks that are necessary for the understanding of intricate design couplings. Perpetual cross-examination of ideas by both the man and the machine will encourage creative thought that would otherwise be extinguished by the lack of an antagonistic (and thus challenging) environment. Computer-aided design concerns an ecology of mutual design complementation, augmentation, and substitution.
Creative Commons Attribution 4.0 International License (CC-BY 4.0)
