Chapter 10

The language presented in this chapter is designed as an integral part of the active computer support of human interpretation in design. It is structured for maximal plasticity so that designers can create and modify terms that express their ideas and their interpretations of their developing designs. At the same time, it must serve as a programming language used to instruct the computer in what computations to make. As part of a hypermedia substrate for design environments, it needs to provide expressive functionality useful for building user interface components and for exploring the hypermedia database.

If one thinks of a computationally active medium for design as incorporating a variety of “agents” that respond to events by computing information for messages and displays, then the Hermes language must serve as a language of agents. It must be able to analyze information in the database—using the customized terminology that particular designers defined within their perspectives—and format the results of computations on that information for display to the designers using the system. In the people-centered Hermes system, the agents do not change stored information, because such changes are left to the direct control of the human designers.

A central question addressed during the development of the Hermes language was how to make the language appropriate to the nature of the human-computer interaction that should take place in a design environment. The Hermes language grew out of the query language of the Phidias design environment, discussed in Chapter 7. The Phidias language was an attempt to provide a language that was “English-like” in appearance in the hope that it could be used by designers who had only a tacit understanding of what expressions in the language meant (i.e., what the expressions accomplished computationally). However, Part II argued that tacit understanding by itself was often insufficient; that interpretation required making some things explicit. That was one reason a language is needed at all. Designers cannot rely exclusively on pre-linguistic “human problem-domain communication” as illustrated by the Janus system, but must sometimes be able to articulate their understanding in words. Language and explicit understanding are required to discover innovative interpretations, to share ideas with collaborators, and to create computer representations. On the other hand, explicit knowledge must be founded on tacit understanding and it is only required during creative interpretive acts, not when tacit understandings meet the needs. So Phidias’ approach to a tacitly understood language provides a promising alternative to traditional programming languages that require a sustained high degree of explicit awareness; but it is not sufficient by itself.

Of course, the scope of the original Phidias query language was quite limited. The Hermes language extended that functionality to meet more of the expressive needs of design environments and of the designers who use them. During this process, the evolving language was subjected to a series of programming walkthroughs (Bell, et al., 1991) to evaluate its usability for writing programs. A primary result of these walkthroughs—which are documented in detail in Appendix A—was the conclusion that significantly more support was needed for explicit understanding of computational issues. However, previous evaluations of the Modifier system summarized in Chapter 7 had shown that a purely explicit approach—even with significant support mechanisms in the interface—was not the answer either.

The theory of computer support from Chapter 6 suggests that an adequate language must support a dynamic movement between tacit and explicit understanding. (1) Routine reuse of expressions can be largely tacit. (2) Innovative modification requires a certain amount of explicit analysis. But even here, only the domain relationships and certain features of the representations need to be made explicit. Much of the computational “doctrine”[1] associated with general purpose programming languages does not need to be made explicit because it would only distract from the problem-domain concerns. Much of this can be kept tacit. The Hermes language represents an attempt to relieve the end-user of such programming doctrine as much as possible.

Relieving the end-user of technical doctrine of programming does not mean that designers using Hermes never need to worry about the explicit structure of the knowledge they are taking advantage of. On the contrary, the analysis of interpretation in this dissertation stresses the necessary role of explication in furthering normally tacit understanding. Rather, the attempt is merely made to minimize the amount of doctrine that must be learned that is unrelated to design. Designers are often predominantly visual, holistic, intuitive thinkers; the symbolic, detail-oriented, precise, mathematical character of programming language doctrine is particularly burdensome for many skilled designers.

Section 10.1 elaborates on the principles that have gone into the development of the Hermes language, including the necessity of supporting both tacit and explicit understanding. The uniqueness of the Hermes language is the way in which it strives to combine the problem-domain centered communicative goals of domain-specific design environments like Phidias and Janus with the computationally expressive goals of general purpose programming languages like Pascal and Lisp through this mix of tacit and explicit understanding.

Section 10.2 shows at an in-depth level how a number of the basic mechanisms of programming languages are available in the Hermes language in ways that require minimal explicit understanding of technical doctrine by system users: Abstraction is accomplished by ordinary naming, with no assignment statements. Iteration takes place automatically without control structures. Typing is maintained by the implicit organization of the syntax options. Recursion is defined without explicit concern for halting conditions. Variables are generally avoided in favor of the application of successive operators; where necessary, deictic pronouns can be used to reference computational elements. Quantification operators can be applied directly to lists without use of explicitly bound variables. Other examples of the encapsulation of explicit mechanisms of computation in tacitly understandable forms are developed in Appendix B, where sample applications using them are also described. Of course, users of the Hermes language need to learn doctrine specific to the use of this language, but that is at a higher level of representation (closer to concerns of the problem domain) than doctrine for a general purpose programming language. Appendix C defines the complete syntax and semantics of the Hermes language.

Section 10.3 illustrates the use of the Hermes language for defining interpretive critics. Interpretive critics provide a final example of the synergy of Hermes’ support for interpretation, exploiting the combination of the integrated substrate, perspectives, and the language. First, the critics from Janus are redefined in the Hermes language. Then, the privacy critics from Chapter 9 are analyzed computationally. A number of the mechanisms discussed in Section 10.2 are shown at work here. This spells out in some detail one way in which Hermes can respond to the challenge from back in Chapter 3, to represent in a computer system Desi and Archie’s concerns about privacy. The advantages of the Hermes approach are: definitions are made at a higher level of representation, the definitions can be more expressive, and alternative definitions can be organized in different perspectives.

[1] The term doctrine refers to guiding knowledge that must be understood in order to use a programming language. For instance, most general purpose programming languages require that programmers know doctrine about when and how to use iteration control structures. The programming walkthrough methodology is designed to assess what doctrine is required for a given task in a language.

Chapter 10. A LANGUAGE FOR SUPPORTING INTERPRETATION