10.1.     An Approach to Language Design

The Hermes language is the result of following several principles arising from the theory of computer support and the review of design environment needs in Part II. These principles are:

1.   Support a mix of tacit and explicit understanding.

2.   Provide a people-centered approach.

3.   Meet the needs of design environments.

4.   Offer an end-user language for non-programmers.

 This section will discuss how the Hermes language adheres to these principles.

1. Support a mix of tacit and explicit understanding. The Hermes language stresses different priorities than traditional computation-centered language designs, resulting in a different set of design decisions and a different character to the language. The contrast between the Hermes language and the Fp functional programming language proposed by Backus (1978), on which the Hermes language is formally modeled, or the Pascal procedural language in which it is implemented makes this point graphically.

Here is a task like that posed for the programming walkthroughs reported in Appendix A: Suppose you have a hypertext database with issues in nodes of two types: question and problem; answers to the issues in answer nodes connected by answer links; and arguments for the answers in argument nodes connected by argument links. (See Figure 10-1.) Now, you want to know: which issues have four or more arguments associated with them (via their answers).

Figure 10-1. A database of design rationale.

This could be accomplished by first defining issues as questions and problems and defining rationale as arguments of answers. Then you could define the query using these newly defined terms as:

issues that have more than 3 rationale

Notice how this “program” in the Hermes language is a simple statement in domain terms of the desired results. All the computations that the computer must carry out to produce the query results are implicit: iterating through all the questions and problems in the database, following each of their answer links (if any) and their argument links (if any), accumulating and counting their rationale nodes, filtering out all the issues that do not fit the condition.

The statement of the query in the Hermes language contrasts with its formulation in other programming languages. First, it has an appearance that seems easier for non-programmers to understand tacitly than its equivalent in Fp, even though the Hermes language is formally close to Fp:

(have-Q-R [>3, rationale]) issues

In this Fp declarative statement, much of the computation has been explicitly symbolized in abstract mathematical formalisms of application, composition, and comparison. Even so, the functional approach of Fp using successive composition of operators—which Hermes borrows from Fp—avoids the step by step detail of a procedural language. The following procedural pseudo-code shows what this query would require in a procedural language, and in fact how it is computed (behind the scenes) even in the Hermes system:

begin

list0 := empty list;

list1 := all nodes with Kind = question;

list2 := all nodes with Kind = problem;

list3 := list1 append list2;

for i = 1 to size of list3 do

   list4 := empty list;

   for each link type from node do

        if link type = answer

             then for each linked node do

                  for each link type from node do

                       if link type = argument

                            then add node to list4;

   if count of list4 > 3

        then add node to list0;

return list0;

end;   

Traditional general purpose programming languages are based largely on mathematical models of fully explicit expressions. To name some of the most popular historical languages, Fortran is based on algebraic formulas, Cobol on business arithmetic, Apl on matrix algebra, and Lisp on symbolic logic. Assembly languages are necessarily closely modeled on the architecture of computer CPUs. Most recent languages are derived from combinations of these prototypes. Even Backus’ Fp language, which is an attempt to break away from the von Neumann and lambda-calculus models, is strongly influenced by Apl—particularly in its outward appearance to the human programmer. All these languages have been developed under severe pressure to optimize usage of computer resources (memory locations and cycle time). This has led to the following problem: programming languages are necessary for empowering people to communicate with and through computers; however, the way in which the predominant languages are closely based on mathematical models make them difficult for many people in many situations to use to express themselves.

Natural languages that societies have historically developed for their own expression and interpersonal communication needs have very different characteristics from these programming languages. They tend to support informal, tacit, contextual, situated expression. Thus, they are very dependent on human intentional comprehension of semantics and communicative intent. They feature a highly generative phrase structure and huge vocabularies that evolve historically. They develop under the constraint of cognitive ease for the human speaker and vocal brevity (Grice, 1975).

Now that computer resources are several orders of magnitude less scarce than in the past while human cognitive resources are being overwhelmed with the complexities of the information age, it seems time to consider designing programming languages or end-user languages in which some of the burdens are shifted to the computer. That is, while a mathematical basis for languages may be important for theoretical reasons, practical considerations of supporting the needs of users without burdening them unnecessarily suggest that the logical computational structure of the language should often be kept tacitly hidden in favor of a higher-level structure close to the user’s explicit concerns. Computers increasingly have the power to manage the translation between these levels to relieve the user of that burden.

The goal of the Hermes language is to make communication with the computer system cognitively and interpretively easier for people. It tries to do this by hiding many computational details, leaving it up to the computer software to take care of them. It allows designers to build their own vocabulary incrementally, using terms familiar from their domain of work. The vocabulary can grow through a history of use, with different people developing different meanings for terms (in their own perspectives) and sharing these meanings (in common group perspectives). The language starts out with a shared basic vocabulary, established as a seeded vocabulary by the design environment builders. Terminology in the language can be reused and modified by subsequent system users, just as natural language words can take on new metaphorical meanings. The language is intended to support interpretation, explication, and interpersonal communication, not just formulaic statement. Section 10.2 will detail what is meant by hiding the computational structure of expressions.

2. Provide a people-centered approach. The slogan of a “people-centered” approach means that the computer system should be controlled by the people with whom it interacts at the points where judgmental decisions must be made that involve the exercise of intentionality. The Hermes language is designed to empower people to express their interpretations and judgments in ways that can affect the computer’s actions and that can also be communicated to other people. By making the design environment programmable, the language lets designers using the system determine how displays, analyses, and critics used in the active computational environment are to be defined. Terms used in the definitions of these displays, analyses, and critic rules can be defined and modified by designers in accordance with their own interpretive perspectives.

“People-centered” also means that the system interacts with people in ways appropriate to human cognitive (interpretive) styles. Hermes features a language for designers (rather than trained programmers) to use. The language is defined as a series of subset languages to facilitate learning by new users. This way, people can work with the language at a level that is comfortable for them. When they need more explicit control in defining revised expressions to capture their precise interpretations, they will have a relatively easy path to exploring language features that are new to them. They can simply move to the next stage of the language in a particular area of the language. For instance, if they need a new definition of a complex expression, they can expand the beginner’s dialog box of syntax options to see the additional intermediate options or they can view the definition of an existing expression and modify it gradually. (An interface for doing this is discussed under point 4, below.)

First it should be noted that previously defined terms and expressions are used by designers most of the time. These can be simply selected from lists of relevant terms, even by a novice. Then there is a beginner’s version of the language that is similar to the Phidias language, which proved easy to use for non-programmer users. This level of the language suffices for defining or modifying most common terms and queries. An intermediate level provides access to virtually all features of the language except those related to graphics. Finally, an advanced level can be used for graphics-related tasks, like defining interpretive critics. Most system displays and component interfaces are defined in the language, so they can be modified through use of the language. It would be possible to add a fully general programming level to the language by providing a programming language interpreter that could treat the syntax options of the Hermes language as predefined functions. This has not been done because the research focus of the Hermes language is to support interpretation in design and to make a language as interpretable as possible for non-programmers. This goal probably does not require a computationally complete language. So, the following levels of usage are supported by the Hermes language:

Novice. Even without defining any new expressions in the language, a novice can still use most of the Hermes system in a flexible way. It is, for instance, possible to define new link Types and node Kinds, although one cannot yet define new computed expressions that refer to them. One can also use all the previously defined (seeded) expressions in the language: DataLists, Predicates[1], conditions, queries, critics, etc. Thus, it is possible to define conditional nodes, conditional links, or virtual structures (queries embedded in nodes) without writing new expressions in the language.

Beginner. This version corresponds roughly to the original Phidias language. It allows the user to define expressions, displays, and critics incorporating Filter clauses. With only 15% of the number of options of the full language, the Beginner syntax provides a good learning experience for most of the features and conventions of the Hermes language. This version of the language features Input Associations, a subset of Associations useful for eliciting design rationale or argumentation. For instance, if an Input Association, deliberation, is defined as issues with their answers with their arguments, then it can be used to control data entry. A special interface feature is designed to create new nodes following the patterns of user-defined Input Associations. Using the definition of deliberation, it will prompt for the text of an issue to be entered; then it prompts for one or more answers to that issue; for each answer it prompts for one or more arguments. Recursive Input Associations can also be defined that prompt for whole trees of data to as much depth as the respondent is willing to go.

Intermediate. The intermediate version of the language expands the computational power of the beginner version, without, however, including the complications introduced by graphics. This corresponds roughly to the level of complexity implemented for the version of the language used in the programming walkthrough (Appendix A) and in the academic advising application (Appendix B). Here, the simple data-entry Input Associations become a subset of the more powerful and complex Associations. Predicates are a modification of Associations to hide some of their complexity when displayed.

Advanced. This version adds the multi-media capability and more sophisticated programming options. Now all the computational capability of the language can be applied to nodes of any medium (e.g., vector graphics, sound, video, and bitmaps). This is necessary for implementing displays or critics that take into account graphical information (distances, spatial relationships, adjacencies, volumes, etc.). [This level of the language has been designed (see Appendix C), but not yet fully implemented.]

Programmer. Ultimately, one might want to give a user full programming power. In a research prototyping environment, one could simply hand over the source code. In a Lisp environment, one can allow the user to enter programs as data that are then interpreted. However, in realistic cases where the source code is not made available and where speed is too much of a concern to use an interpreted language for building the system itself, other mechanisms must be developed. Hermes provides a form of procedural attachment implemented via dynamic link libraries (DLLs) in Windows. This lets the user define a certain number of pre-named functions, using the full power of object-oriented Pascal or C++. These functions can then be attached to nodes or links in the hypermedia database (see active objects in Section 8.2) and referred to by expressions in the Hermes language. [This level of the language has not been explored extensively, but is meant to be suggestive as a response to the limits of programming complex algorithms in the Hermes language.]

These levels of the language extend the idea from Janus of a layered architecture, as discussed in Chapter 7. The layers of the language fill in the two gaps that appeared in Figure 7-2: the transformation distance-3 between the system building environment (Lisp) and the design environment (Janus), and the transformation distance-2 between the seeded design environment and the actual task domain (laying out a particular kitchen). The first of these gaps is filled primarily for system builders who are constructing a new design environment or adding new components to an existing one. When a design environment is built on top of the Hermes substrate, new components take advantage of the substrate functionality, including the language. As shown in Chapter 8, many functions are implemented as windows or buttons that evaluate expressions defined in the Hermes language. That means first of all that functionality can be defined using higher level terms in the Hermes language without the system builder needing to work at the lower level implementation language. It also means that future end-users can revise the way those functions work by modifying the definitions of the terms used in the Hermes language, which is available to them at run-time as well. The second gap is filled primarily for designers using a design environment built on Hermes. They can simply use the terms, displays, and critics that have already been defined. If they need to modify something, the Beginner version of the language is available. If this is not sufficient, they can successively try more advanced versions of the language. This provides almost a continuity of layers to support a range of understanding from tacit work in the problem domain to explicit software programming in the underlying programming environment. (See Figure 9-17 in Section 9.3.)

3. Meet the needs of design environments. Chapter 7 cited the idea of programmable design environments proposed by Eisenberg and Fischer (1992). It was claimed there that Hermes could be viewed as the first implementation of this notion. In fact, the design and development of Hermes was driven by the desire to include programmability as a central feature of a design environment in order to empower designers to define, control, and extend the computational power of the software system in which they carry out their design work.

The desire to have the language refer to, analyze, critique, and display all the varieties of knowledge and representations in a design environment—including information from previous designs in a catalog, palette items for use in new designs, specification decisions, design rationale, domain distinctions, critic rules, etc.—forced the system to become more and more integrated. As the power of the language was extended from its original restriction to design rationale (in the original Phidias query language), more of the knowledge was represented as hypermedia nodes that could be linked in one integrated knowledge base. New forms of knowledge were also added. For instance, conditional expressions could be defined to implement conditional links, conditional nodes, and critics. The increased generality of the system made it easy to add new media, like bitmaps, voice, and video as well.

As the language grew in range and power, the number of its syntax options in the language increased rapidly, despite extensive efforts to generalize and simplify the syntactic structure. In the end, the number of options increased by an order of magnitude. Most of these syntax options (those called “simple” options) directly reflect elements of the multimedia knowledge representation substrate. Many other syntax options (called “computed” options) define combinations of the primitives that are needed for useful computations. The appearance of expressions in the language is dominated by user-defined terms: names of objects, link types, node kinds, names of defined sub-expressions. Otherwise, there are just a few “helper” words that remind people of the functionality of the options. Little is left in its external appearance of the language’s computational internal nature. Thus, the Hermes language appears to be a “new” language, although it is really basically the result of adapting a stripped-down functional programming approach to meet the needs of a design environment.

Despite its adherence to the notion of a programmable design environment, the Hermes language is very different from a programmable application like SchemePaint (Eisenberg, 1992). In SchemePaint, the language is used for creation of new objects. In contrast, the Hermes language is “non-imperative” (Schmidt, 1986). Evaluation of expressions in the Hermes language do not change state: they do not create anything new. They navigate through the hypermedia database and collect lists of existing objects. Of course, by means of user interface features, these lists can themselves be saved as new objects. Also, interface features can be designed that use language expressions to organize, modify, or even create objects. For instance, a design rationale prompting component in the interface can elicit and store new argumentation using the Input Association syntax options as explained in Appendix C. The language is primarily geared to the diverse information retrieval needs of designers.

Design environments have a variety of data retrieval, manipulation, and display needs. In a hypermedia-based system like Hermes, these needs can generally be categorized into three groups: (a) to generate lists of information, (b) to selectively choose items from lists, and (c) to navigate through the inter-connected network of the database. This corresponds to the three categories of operations that Abelson & Sussman (1985) emphasize for functional computer programs: to enumerate, map, and filter lists or streams of information.[2] The Hermes language syntax provides three primary classes of terms to operationalize these functions: DataLists, Filters, and Associations, as indicated in Table 10-1:

Table 10-1. Correspondence of language uses, operations and classes of terms.

(a) Many forms of lists must be generated (enumerated) in a design environment. In a system built on top of the Hermes substrate, virtually all displays in the user interface are constructed dynamically from such lists. The Hermes language is designed above all to provide a flexible means for defining lists of items stored in the database and useful for interpretive tasks in the represented domain. In this sense, the Hermes language is a database query language. The Hermes language is optimized for expressing queries in this environment and for retrieving the requested information efficiently in useful formats. Unlike SQL (a general purpose query language for relational databases), it is designed for an object-oriented, multimedia database in which items are linked together in hypertext style. It differs from SQL in being non-relational and hypermedia-specific. Among the information listings available through the Hermes language are general queries and the basic displays used in design environments, such as design rationale issue-base views, catalogs of past designs, palettes of design components. An example of a DataList that computes the items for a display of some rationale created by Archie is:

issues that have creator archie

(b) Filtering functions of the language are important for implementing critics and for making all displays relative to design decisions encoded in specifications, constructions, or design rationale. For instance, using the language one can define a display of all catalog items that pass a Filter referring to the existence of specific palette items in a certain construction, answers resolved in the design rationale, or selections made in a specification listing. Perspectives provide another filtering mechanism in Hermes, allowing only nodes that are defined in the currently active perspective to be processed by the language. The two filtering mechanisms can be combined in expressions in the language like:

issues in context desi’s habitat perspective that have creator archie

(c) Navigation through the hypermedia database (mapping) is also accomplished with the Hermes language. A good example of such navigation is shown in Figure 10-1 with the expression:

issues that have more than 3 rationale

Here, the expression rationale, defined as arguments of answers, navigates from each issue node across its answer links to new nodes and across their argument links.

Table 10-2. Major syntactic classes of the Hermes language.

The three major syntax categories of the Hermes language (DataLists, Filters, Associations) provide the three primary functions required for design environments: (a) definitions of lists of nodes, (b) expressions for filtering out nodes not meeting stated criteria, and (c) operations to traverse various kinds of associations. These support the situated, perspectival, and linguistic character of interpretation by naming representations of things in the design situation, filtering out objects for display based on viewing criteria, and providing expressions for exploring semantic associations. Objects in each of these three categories can be either (1) reused or (2) refined by combining expressions in useful ways. This defines the six primary syntactic classes; four other classes provide auxiliary terms and features. The syntactic classes are listed with brief descriptions in Table 10-2.

The central syntax classes of the Hermes language are (a) DataLists, (b) Filters, and (c) Associations. In addition, (d) the Media elements define several syntax classes, one for each kind of allowable multimedia content in the hypermedia database that is traversed by the language: Character, Number, Boolean, Graphic, Image, Pen, Sound, Video, Animation, and ComputedView. (e) The Terminology options provide the connective terms for joining multiple items together and for counting items, as well as certain definitions useful for graphical computations; these include three syntax classes for user-definable options: Count, Quantifier, Measure; and eight syntax classes that are system-defined: Connective, Combination, Distance, Units, Dimension, Attribute, Value, and LanguageType. In addition there are three hypermedia classes that are part of the syntax: Contexts, NodeKinds and LinkTypes. The syntax classes are divided into Simple and Computed options. The Simple options define a single operation for producing a result. The Composite options define legal combinations of applying one operation to another. This defines the operator algebra that is at the heart of the Hermes language. It is discussed below. Table 10-3 (below) provides sample options from each of the classes listed in Table 10-2 (above).

The DataList, Filter, and Association options constitute the majority of the syntax options. The Simple options are all defined as primitive operators. For instance, Simple DataLists return a node or list of nodes as their result. DataList, Filter, and Association (both Simple and Computed) evaluation functions all take a DataList as input and return a new DataList as a result. This DataList result format acts as a stream of data items that passes through the operators to generate new items, filter out items that were there, or map from the old items to associated new items. Because of this uniform format, any of the operators can be applied successively to the results of any other operators. This allows the unlimited nesting of phrases and application of operators that makes the Hermes language highly generative.

Table 10-3. Examples of syntactic options for the Hermes language.

In Hermes, only certain combinations of applications are permitted, as defined by the Computed options. If the Simple options were incorporated as predefined functions in a general programming language like Fp or Scheme, then any combinations of operators could be evaluated. However, a judgment has been made in designing Hermes to limit the combinations to semantically meaningful and useful options. That accounts for the seeming proliferation of options. In fact, however, the majority of options are nothing but combinations of other options applied to each other. For these combination options, the semantics are trivially defined, as shown in Appendix C in which the denotational semantics and the corresponding implementation code for the evaluation function of one such combination option is shown. The Hermes language is a carefully constrained language, designed to promote relatively tacit usage by structuring the choice of operation combinations to avoid many problematic expression definitions and to guide the language user.

Figure 10-2. An example of hypermedia navigation.

4. Offer an end-user language for non-programmers. The use of the language in Hermes can be made appropriate for non-programmers in many ways through interface features. Some examples were already given in Chapter 8. Consider how navigation through the hypermedia database (mapping) is accomplished with the Hermes language. An example of such navigation is shown in Figure 10-2 (above). A textual node has been selected in a Design Rationale window by clicking on it. This brings up the Navigating the Hypertext window. The selected node has been displayed in the top of this window and the default option of “Navigate out-going links” has been chosen. The list of “Out-going Links” displays “issue”, indicating that the selected node is associated with out-going links of type issue to other nodes. The list of Predicates[3] displays three terms that have previously been defined in the Hermes language; these terms are all defined with expressions that include issue as their initial traversal, so they are relevant to the selected node that has issue links. If the user had selected “issue” under “Out-going Links”, then a new Design Rationale window would have been displayed listing all the nodes navigated to by following issue links from the original selected node. In the case shown in the figure, the user has instead selected the Predicate discussion. Discussion is defined in the Hermes language (either in the seed or by a previous user) as a series of link navigations beginning with issue links. So the display produced in the new window is an indented list resulting from the navigations defined by the language expression named discussion.

The example just given illustrates a number of points about language usage in Hermes. First, expressions (like discussion) can be reused without explicit concern for their detailed definition, particularly if their name indicates their function adequately. Second, rather complex displays can be defined relatively easily. If one wanted to, one could modify the definition of discussion or define a new term based on it. The new term could use Filter conditions to eliminate items selectively as well. For instance, one could define a new Predicate bunk discussion as: discussion that contains ‘bunk’. Then the list of Predicates displayed in the Navigating the Hypertext window would include bunk discussion and selection of this option would result in a display that only listed items including the word “bunk”. Third, language usage can be integrated into the user interface so that it feels like tacit navigation through hypermedia rather than explicit querying with a language. The use of this language need not have the look and feel of programming, even when new expressions are being defined for accomplishing arbitrarily complex computations.

When an expression must be explicitly programmed, interface support is available to reduce the cognitive burden of recalling syntax options, strict formats, expression names, or terminology spellings. As part of the attempt to reduce programming errors that would frustrate a non-programmer, a direct manipulation interface is provided for use, reuse, modification, and creation of expressions in the Hermes language. Strictly speaking, this is not part of the Hermes substrate, but belongs to the interface of a design environment built on top of the substrate. It is presented here simply to suggest one solution to the problem of supporting people to use the Hermes language with minimal cognitive overload.

*    By presenting all relevant options on the computer screen at each stage and requiring expressions to be built up by choosing from these dialog options, the user is relieved of having to remember the various legal options.

*    Similarly the problem of entering the precise proper format and spelling is solved. Novice programmers are particularly frustrated by punctuation and spelling errors during program input.

*    The interface presents definitions of terms in a readable format. Given that expressions in the Hermes language often read much like English, it is important to avoid the impression that the system can understand arbitrary English formulations. The restriction to a visible menu of choices makes the restrictions clear and unavoidable.

*    The same dialog boxes that are used for defining new expressions encourage the reuse of previously defined expressions. Old definitions can be reviewed with the dialogs to see their internal structure, and the definitions can then be modified and reused.

Figure 10-3. Dialog boxes for defining DataList expressions.

Figure 10-3 shows the three dialog boxes for defining a DataList expression. This is typically the starting point for defining expressions in the language, such as queries or critics. It is also possible to start with other dialogs to define conditional expressions, numerical computations, and so on. The leftmost dialog, labeled “DataList options,” is the first dialog to appear under conditions in which one needs to define a new DataList. If one wants to select a previously defined DataList expression—whether defined as part of the Hermes seed, by other system users or by the current user—then a pick-list of the names of all defined DataLists is used instead.

This programming interface incorporates the breakdown of the language into a series of levels for users with different degrees of experience in using the language. This is an example of the mixture of support for tacit and explicit understanding. Even when the system user needs to make interpretations explicit and state them in the programming language, this burden is softened by providing a direct manipulation, construction kit interface for defining expressions and by providing a layered architecture of many levels of successive complexity.

The leftmost dialog presents the Beginner’s version of the syntax. The heart of this dialog is the list of seven small circles, the radio buttons for selecting one of the three Simple DataList options or one of the four Composite DataList options. The first of these options allows the user to simply select a node from a pick-list, which will be displayed when this option is chosen. The second option defines a DataList consisting of all nodes in the database that are of a specified NodeKind. If this option is selected (by clicking the mouse on its NodeKind button), a pick-list of the names of all defined NodeKinds is displayed. The third option retrieves a DataList expression that has been previously defined and saved.

The Composite DataList options lead to other dialog boxes to define constituent parts of the composite expression. The first of these, for instance, has three buttons: “DataList”, “Combination”, “DataList”. If this option is selected, then each of these buttons must be pressed with the mouse before the new expression can be saved. Pressing the first (or the third) of these buttons brings up another copy of the same dialog box so that the constituent DataLists may be selected. For instance, to define a DataList named issues as questions and problems, use this option and press the first button. When the new DataList dialog appears, select the first Simple DataList option and choose questions from the pick-list that appears. Then click the “ok” button at the bottom of the new dialog to confirm this choice. The new dialog will disappear. Then press the “Combination” button. This will bring up a dialog listing the five Combination options. Simply select the and option and click the “ok” button. Then define the DataList for the third button as problems. Now the expression questions and problems will show in the small window near the bottom of the DataList dialog box. Press the “save DataList” button below there. A small dialog will ask for the name of the new DataList that has just been defined. Type the word issues and the new expression will be part of the Hermes system.

Below the list of options in the DataList dialog are buttons labeled “more DataLists” and “graphic DataLists”. These bring up the dialogs with the Intermediate and Advanced DataList options, respectively. They are also shown in Figure 10-3. They work the same way as the options in the first dialog, which remains on the screen and controls the overall expression definition process. This is how a user advances from the Beginner to the Intermediate or Advanced levels of the language based on their specific needs.

One more button should be mentioned in the basic “DataList options” dialog box. That is the uppermost button: “reuse a DataList”. Pressing this button brings up a pick-list of defined DataLists. When one is selected from this list, the list disappears and the definition of the selected DataList appears in the dialog. First it appears in the display window in its narrative format. But it also appears in the options in the sense that the option that was used for defining it is now selected in the dialog. Pressing the buttons for that option will bring up dialogs that are also already displaying the constituent parts. This provides a way of exploring the structure of a defined expression. If anything is changed on the subsidiary dialogs and confirmed and saved, then the definition of that expression will be modified accordingly (within the currently selected perspective).

While the foregoing description and its accompanying figure may seem complicated, that is partly because it is harder to describe this process explicitly in words, covering most of the various possible actions, then it is to use the direct manipulation interface to make selections needed to accomplish a specific task.

 The Hermes language represents an attempt to push a particular approach to language design as far as possible. This is what makes the Hermes language distinctive. The approach is motivated by the theory of computer support of interpretation. It includes an effort to balance support for tacit and explicit understanding, promoting tacit activity whenever possible, even during the accomplishment of explicit programming tasks. It tries to develop an expressive and extensible programming language for people like designers who may not be experienced at computer programming. To do this, it hides many of the computational mechanisms (as described in the following section), and constrains the syntax of the language. Of course, there are trade-offs involved in keeping mechanisms hidden and in limiting options to enforce meaningfulness of expressions. The Hermes language has great flexibility and expressivity. It is infinitely generative and arbitrarily complex. But it is far from being Turing complete. There are many definitions of lists that cannot be expressed in it, but that are relatively straight-forward to program in Pascal or Lisp, for instance. Subsequent examples and analysis in the remainder of this chapter and in the Appendices should show the language’s ability to formulate easily and tacitly the expressions most useful for design environments, as well as pointing out the limitations that can arise in more complex circumstances.

Go to top of this page

Return to Gerry Stahl's Home Page

Send email to Gerry.Stahl@drexel.edu

This page last modified on January 05, 2004