Languages for Architecture Machines

“The world view of a culture is limited by the structure of the language which that culture uses.” (Whorf, 1956) The world view of a machine is similarly marked by linguistic structure. At the present time, however, machines have denatured languages—codes. Codes are invented for specific purposes and they follow explicit rules, whereas languages develop and they evolve. But language presupposes a culture and presumes an understanding, two features we are not about to ascribe unequivocally to machines at this time.

If you are in conversation with a machine and using a machine-oriented code, when the mechanism replies, you report a “reaction.” However, employing a man-oriented code—a pseudolanguage—you might attribute to the machine an apparent “understanding.”

There are many man-oriented languages. There are languages of gestures and smiles, a language of posture, a language of touch. The reader should be referred to the important ongoing work of Warren Brodey and Avery Johnson (1969); this section is concerned with only one subset, a formal language that architecture machines must have at the very beginning—English. URBAN5 does display an apparent understanding of English. It does use context as the prime operator in translation. It has the assumed context of architecture. Modes further define context. However, throughout any English conversation with URBAN5, the overshadowing assumption is that the designer will talk about that which is at hand when he pushes the SPEAK button. Or if he asked a question, the assumption is that his answer is indeed a reply to that inquiry. With these assumptions, URBAN5 breaks down a sentence using dictionaries that contain both words and phrases. Each context (mode) has separate dictionaries.

In the case of criteria specification, the interpretation mechanism looks for a dyadic relationship and a desired answer. A mathematical summation or ratio houses the constraint. The interpretation routine passes to the conflict mechanism one or two operands (quality, symbol, solid or void, generic, topographical term), an operation (sum or ratio), and a desired result (number and units). For example, from the criterion, “50 percent of all residential units must have outdoor access,” the transformation is Ratio =

In a simpler case, when a direct question is asked, like “Does there exist any previous material to read from tape?”, the designer’s response can be recognized with as little as five or ten dictionary words. In some cases, extra words might be stored in the translation mechanism because the author’s bad spelling requires categorization of words under proper and improper forms.

English responses by URBAN5 are all preprogrammed sentences. The machine has a repertoire of about five hundred phrases which provide a source of replies that can be combined with quotes from the designer. URBAN5 did not achieve the interesting capability of creating its own error messages from words and small phrases. And the reader should not suppose that a group of architects working on computer-aided urban design have solved or even seriously tackled linguistic problems. The reader should refer to the well-documented projects of Green (et al., 1963), Bobrow (1964), Weizenbaum (1967), Raphael (1964), and Kellogg (1967).

URBAN5’s diversion into linguistics animates the desire for natural interaction that underlies the entire system. Also, the crucial and not-so-obvious role of context once again manifests itself. Linguistic studies by professional linguists, like mechanical translation, have often ignored context because it is difficult. A machine translation from Russian to English came up with a now classical error: “Time flies like an arrow” became “Time flies enjoy eating arrows.” It is not surprising that context is so important. Even in human understanding, a knowledge of context, usually a priori, is necessary.

One of the reasons that machines do not speak English is that linguists have spent so much time on syntax and so little time on semantics. Only after fifteen years of research does there now appear to be a general consensus that semantics is the key to machine understanding of natural languages. Of course, nobody knows how to study linguistic associations and meanings without becoming thoroughly involved in syntax, noun-verb structures, and so forth.

One exercise in languages for architecture machines is the computer program STUPID. This routine was developed at first as a joke. It took a string of text, looked at a history of previous sentences, and randomly pieced together a response. Though the syntax was poor, STUPID was able to make clever replies using only statistical operations based on the kinds of words it was receiving. Later, STUPID was given Robert Venturi’s book, Complexity and Contradiction in Architecture (1966), and its replies were little more than cute. The experiment does prove, however, that if you are going to ignore semantics, you might as well ignore syntax. STUPID ignored both. A dialogue between Warren Brodey and STUPID went as follows:

Brodey:
My name is Warren Brodey
STUPID:
My name. What is Warren Brodey
Brodey:
What are evolutionary environments?
STUPID:
What are the silliest machine that ignores context?
Brodey:
Tell me, how do butterflies make love?
STUPID:
Tell me how do butterflies will be little concern for you.
Brodey:
Why do you insist?
STUPID:
Why do butterflies make love?
Brodey:
Fink
STUPID:
Fink, why do butterflies make love
Brodey:
As a lover you are a torture
STUPID:
As a problem for you have ever seen
Brodey:
Popapolartuil
STUPID:
Popapolartuil yes, that is Warren Brodey

Why should a machine talk English? Is it a false anthropomorphization or a true facilitation? To assume that it is indeed a true facilitation, it is necessary first to distinguish language from style. For example, the error message, “Boo boo, you goofed again,” as a style of communication is surely unnecessary. Conversely, a number appearing on a cathode-ray tube referring the designer to a manual, is equally unnecessary. With almost no effort an explanatory paragraph can be displayed on a scope or a hard copy retrieved on a printer. A string of characters can be effortlessly stored on a disk and retrieved and displayed in less than a twentieth of a second.

The argument, however, should not be confused with the reverse case, numerical answers unnecessarily clothed in words. An architect, in a cost estimation procedure, for example, probably expects the cost per square foot rather than the comment, “cheap,” “okay,” “expensive,” or “forget it.”

The main issue is not only English versus pidgin English versus codes. The question is one of language that is not only “human discourse” but evolutionary discourse. Learning the rigors of a computer language should be unnecessary except as a mental exercise or training. On the other hand, when using written English, it might become cumbersome to write out words like “residential units” after the second or third spelling. One aspect, probably the simplest one, of evolutionary linguistics would permit each designer to select some anagram to refer to residential units if he so chooses. In effect, each designer should be able not merely to converse in English but simultaneously to construct his own private shorthand or telegraphese that might, in fact, be gobbledygook to another architect or another machine.

This all implies a congenial idiom, but it is still a narrow channel of communication that ignores, as we have said, the language of gestures and the intonations available in human face-to-face contact. The informal sensory and motor augmentation of understanding is verily “unavailable to readers of telegrams—be they computers or humans” (Weizenbaum, 1967). But who designs environments by telegram?