Language Design and Informal Programmers

Reasons for my interest

I have developed a preliminary framework, the ‘Cognitive Dimensions of Notations’, in which to analyse both language design (seen as an information structure) and type of activity (at a generic level). Such an understanding needs to bring together sociological data (what do people really do), cognitive data (theories of parsing, problem-solving, working memory, etc), and concepts from the emerging but as yet un-named realm of information structure analysis. The task is to seek a successful pairing between design and activity. Some details of the framework are given below.

The ‘blended user’ is a new concept, a different position on the continuum. My framework describes how the user’s activity is supported by the language and the environment, so at the workshop I hope to gain further knowledge of what blended users really do and to provoke others and myself into collecting relevant data, relating them to my framework (or to other more successful accounts, if available) and assembling them into a coherent picture.

Against panaceas

For example, a common prescription is "use a strong metaphor", as in LabVIEW, say. A series of experiments by Blackwell (1998) showed that the presence of a strong metaphor failed to help participants who represented typical potential end-users; performance with the metaphor was very similar to performance without the metaphor. Even a deliberately misleading, poor metaphor made little difference, either for or against. Practically the only reliable effect found in the series of studies was that a strong, concrete metaphor inhibited the development of useful abstractions - whereas of course, development of useful abstractions is precisely what we do want to encourage. Obviously one doesn’t want to over-emphasize a single series of experiments: metaphors may still have their uses; but at least we can be sure that providing a metaphor is not a panacea.

Another common belief is that some programming languages are ‘intuitive’ or ‘natural’. It is true that certain operations performed on natural languages like English are also performed on artificial languages like Pascal; for example, the ‘sentences’ have to be parsed into higher-level constructs such as ‘programming plans’, and it turns out that models of human parsing can successfully be extended to make predictions about human parsing of programming languages (Green and Borning, 1990). Nevertheless it is hard to consider any programming language as being even remotely natural in the cognitive science sense of a natural language. (How would you say "I really wish it had rained last Tuesday" in Pascal? How would mother-baby interaction work in C++?) Perhaps, when people say that a programming language is ‘natural’, they mean that it conforms well to ‘mentalese’ (Pinker, 1994), the language in the head. Yet we know next to nothing about mentalese, and from what we do know, all the indications are that it is not structured much like a language. So perhaps when people say a language is ‘intuitive’ or ‘natural’ they mean it is easy to learn or easy to use. But the research I and others have done has consistently shown that languages are good for certain tasks and bad for others (the ‘match-mismatch’ hypothesis of Gilmore and Green, 1984), showing that overall panaceas are unhelpful: we need analyses that match language, task and user. Similarly work by Détienne (1990) has shown that the object model, which at present is the most commonly proposed recipe for ‘naturalness’, presents novices with considerable difficulties in both learning and comprehension, implying that the supposed naturalness of OO is entirely artificial. That once again leaves us with the conclusion that rather than make grand assertions about one language being more natural than another, we should break the concept up and consider it in detail, trying to theoretical arguments to predict which particular tasks are easy or difficult.

Lastly, visual programming is seen by some as a panacea. Folk psychology figures largely in the reasons given by computer scientists for supporting VP (Blackwell 1996a, b; Whitley and Blackwell, 1997), some of them advancing tired adages like "a picture is worth a thousand words" and others advancing ill-digested wisdom about brain function and laterality. Empirical studies have shown that visual languages, just like text languages, highlight some kinds of information at the cost of obscuring other kinds, whether the language is based on control-flow (Curtis et al. 1989) or on data flow (Green et al. 1991), or even on Petri nets (Moher et al. 1993). Visual languages are interesting, even exciting, because they highlight some kinds of information and allow some kinds of manipulation that are different from text representations, but they are no panacea.

Information Structure Analysis

Activities

Environment

Dimensions

Each of these has to be considered in detail. A full account requires a description of subtypes, if relevant; plus examples, a formal definition, a cognitive account, and an account of the ‘design manoeuvres’ by which it can be traded against other dimensions. For example, viscosity means resistance to change: the cost of making small changes. (Viscosity in hydrodynamics means resistance to local change – deforming a viscous substance, e.g. syrup, is harder than deforming a fluid one, e.g. water. It means the same in this context.) As a working definition, a viscous system is one where a single goal-related operation on the information structure requires an undue number of individual actions, possibly not goal-related. I distinguish between repetition viscosity and knock-on viscosity.

Viscosity can be reduced by specialised editors, at the cost of certain trade-offs: usually at the cost of increasing the abstraction level, which may in turn mean increasing the level of enforced lookahead to avoid premature commitment.
 

Abstraction	types and availability of abstraction mechanisms
Closeness of mapping	closeness of representation to domain
Consistency	similar semantics are expressed in similar syntactic forms
Diffuseness	verbosity of language
Error-proneness	notation invites mistakes
Hard mental operations	high demand on cognitive resources
Hidden dependencies	important links between entities are not visible
Premature commitment	constraints on the order of doing things
Progressive evaluation	work-to-date can be checked at any time
Provisionality	degree of commitment to actions or marks
Role-expressiveness	the purpose of a component is readily inferred
Secondary notation	extra information in means other than formal syntax
Viscosity	resistance to change
Visibility	ability to view components easily

Application to end-users and blended users

It is reasonable to view end-users in the light of studies of novice programming, and to postulate that as many as possible of their actions must be clearly goal-related and be seen to make progress in the application domain. Writing a formula is directly goal-related, defining a template or a class hierarchy is not clearly-goal related. (Anderson et al., 1984).

Hidden dependencies, diffuseness and high viscosity can therefore be tolerated, because modification and search are rare; closeness of domain mapping is essential, because steps must be goal-related. Premature commitment can not be tolerated, because the enforced lookahead is difficult for untrained designers, and for the same reason abstractions must be avoided; since spreadsheets require very little lookahead and are notably devoid of facilities for forming abstractions, they meet those requirements well. Errors are a worry to these users (Hendry and Green) but they lack both tools and know-how for systematic error-testing and defensive design.

Nardi and Miller also reported that spreadsheets were much used, in the organizations they studied, as tools for communication across departmental boundaries. This is another reason for avoiding abstractions, which probably hinder ready communication and comprehension.

Consideration of end-user programming in other contexts seems to support similar conclusions, although detailed studies are few.

How will the framework cope with the ‘blended user’? That depends on what blended users do, of course. My anticipation is that comprehension will be more salient, since scripts will be shared and stored; also non-goal-related activities will be more acceptable to blended users and they will be more concerned to invest in the future by making good design decisions at an early stage; however, substantial rewritings and other forms of modification will be unacceptable through time pressures. Under these conditions, limited forms of abstraction will be acceptable (abstraction tolerance, rather than abstraction hunger); but if modifications are not a prominent feature, such abstractions will be designed to increase closeness of mapping and comprehension, rather to provide routes for change or re-use. The increased interest in comprehension will mean that tools should provide better facilities for secondary notation and for perceptual mapping. Error-proneness will be more important to blended users, whose jobs may include responsibility for error-avoidance. Hidden dependencies will therefore be less tolerable.

If these speculations are correct, the spreadsheet architecture would need to be considerably altered before it became as well-suited to the blended user as it has proved to be for the end-user. The most prominent type of blended-user programming tool at present is the scripting language, and a detailed consideration of these languages (and their environments) together with data on the activities and responsibilities of blended users may lead to strong predictions and design suggestions.

References