Abstract

Abstract Research into the cognitive aspects of programming originated in the study of professional programmers (whether experts or students). Even "end-user" programmers What is Programming? Goodell's excellent website devoted to end user programming Programming is in fact seldom defined in modern research publications. An earlier programming textbook from 1959 gives a typical formulation for that time: "This sequence [of basic operations] is called the program and the process of preparing it is called programming" [32, p. 4]. Programming is the "spadework" of finding a precise mathematical formulation and method of solution, possibly notated in a "convenient problem-oriented language" whose symbols are "more closely related to the mathematical problem to be solved". The major changes since this was written are a) that many computer users do not now consider themselves programmers (when Weinberg wrote his early monograph "The Psychology of Computer Programming" As programming applications have moved away from the mathematical domain typical of early computing, the nature of the basic operations, the symbols in programming languages, and the formulations or methods of solution have all evolved. An introductory chapter to the book "Psychology of Programming" Three definitional questions Who is a programmer? The lines of professional demarcation within the software development community have always been fluid as a result of changing programming tools. For example, the distinction between "analysts" and "programmers" blurred when 4GLs enabled programming at a level of abstraction that was comparable to the vocabulary of the analyst. Analysts thus became analyst/programmers in the 1980s, and were simply called programmers again by the 90s. The same trends occurred in other specialist jobs. Unit test engineers were initially programmers (who wrote test harnesses), then In Proceedings of the IEEE Symposia on Human-Centric Computing Languages and Environments, pp. 2-10. simple operators of regression test tools, then programmers again as the testing tools became programmable. Recent trends have been to increase the number of people who might do programming in the course of their work. Almost all major software applications include scripting or macro languages of some sort, usable to configure and customize the behaviour of the application. Most operating systems include scripting languages. One of the most widely used classes of software application, the spreadsheet, is itself a declarative programming language. Many people who are not professional programmers use spreadsheets to create large and complex applications, thus inheriting all the software engineering problems of specification, design, testing and maintenance. End-user development, end-user customization and enduser software engineering have all been proposed as terms expressing the challenges faced by users encountering these new tools. Some of those terms apparently deemphasise the sophistication of the programming required ("customization"), while others emphasise the fact that large and complex design projects are difficult whatever the tools used ("engineering"). Some of these differing emphases in terminology can seem more suited to software product marketing, rather than seriously contending that "customization" means no programming is involved. If a conventional programming language were used to carry out the same tasks, there would certainly be no doubt that these applications were conventional pieces of programming work. But the one aspect in which end-user programming tasks always differ from conventional programming tasks is precisely that the software tools used for development or customization have the potential to be so unlike conventional programming languages. Which of the following can unambiguously be categorised with respect to the boundary between programming languages and other forms of software: Scripting languages? Spreadsheets? Macro languages? Keyboard macros? Configuration files? Java programs? Javascript programs? Server Side Include macros? Cascading Style Sheets? HTML pages? Microsoft Word documents? From the perspective of a non-programmer or end-user, the distinctions between these technologies are not at all clear-cut. All of them are able to produce dynamically modified text documents, and several can potentially be used to create apparently identical results. Yet some of them are classified in professional contexts as being programming languages, and some are not, with the result that when carried out by an end user, some of them may be classified as end-user programming and some not, even though the user may feel that he or she is doing a single task in different ways. This ambiguity becomes acute when the programming is taking place in a context that is completely separate from the workplace. An end-user programmer at work is quite likely to realise that the things he or she are doing could have been achieved by a professional programmer working within the organization. Previous academic studies have emphasized the roles these end users play on the boundaries of professional programming activity within an organization In contrast, a domestic programmer is not usually described as a "power-user". There may still be good reasons why somebody would create a Word macro to save time on a lengthy task at home. We have proposed elsewhere a system suitable for enhancing domestic remote controls with programming abilities In order to avoid these inconsistencies, the first proposal of this paper is that all computer users ought to be regarded as potential programmers, whose tools differ only in their usability for that purpose. The social approval accorded to such skills may increase with time, but this is not a fundamental indicator of inherent cognitive challenge in the task. If it is possible to find interesting programming-like attributes in other kinds of computer use, programming research could be universal and inclusive in its scope, rather than restricted to the experience of "professional" programmers. The next section therefore considers a classification of programming languages that takes account of these user perspectives, rather than conventional definitions. What is a programming language? What aspect of programming languages makes them different to other kinds of computer usage? Consider some of the examples presented above. A web page generated by a Javascript script or Server Side Include macro, when seen in a browser, may appear indistinguishable from a web page written directly in HTML. The difference resulting from the script or macro is that a different viewer, or the same viewer at another place or time, will see a different web page. The author writing the page specifies these differences by adding control information (in the scripting or macro language) to be interpreted by the computer rather than by the viewer. These simple variations might be seen as conflicting with some ideals of modern design for usability. What the user sees when authoring the page is not necessarily what he or she gets when viewing it -a conflict with the ideal of WYSIWYG. What he or she is manipulating is not a concrete instance of the desired result, but an abstract notation defining required behavior in different circumstances -a conflict with the ideal of direct manipulation. Of course these departures from the "ideal" are not a bad thing -they are necessary in order to achieve the task. But the additional challenges to the user are typical of the challenges that distinguish programming activities from those activities that do allow direct manipulation and WYSIWYG. When we consider other examples given above, similar properties are apparent. The distinction between writing an HTML document and a Word document is that the HTML document may look different to different viewers (depending In Proceedings of the IEEE Symposia on Human-Centric Computing Languages and Environments, pp. 2-10. on the size and shape of the browser window, the browser version, platform, available fonts etc). A single decision by the author can thus have multiple consequences -different results each time the document is viewed in a different situation. Once again, this range of effects is produced in HTML by the use of an abstract notation to define required behavior in different circumstances (here, the markup language). As with the use of JavaScript, even the abstractions of HTML provide the opportunity for syntax errors, runtime errors, or bugs in the form of unintended or exceptional behaviors. The same is true even of a keyboard macro. Pressing a key when composing a regular document is a fairly direct manipulation -the character that was written on the key appears on the screen, and can be viewed and retained or deleted in a direct feedback process. But pressing a key when composing a keyboard macro has other effects beyond those that are directly visible. When the macro is executed again in a new context, the results will be different. The user must anticipate this, and use abstract commands rather than direct manipulation commands (e.g. using the "end of line" key rather than pressing the right arrow key until the cursor reaches the end of the line, which would fail with a bug the first time it was executed in a line with a different number of characters). All of these examples, although rather trivial by comparison to the challenges of large software projects, do share important characteristics of conventional programming. The user must: • Decide the intended result of executing the program (requirements); • Identify when it will be executed, and allow for variation in different circumstances (specification); • Choose from a set of technical features that may support this behaviour (design); • Enter abstract control commands as well as data (coding) and anticipate; and • Account for departures from the intended behavior (debugging). All of these things are intellectually challenging, and they increasingly arise in all aspects of computer use. Consider, for example, the definition of a document template, or even a paragraph style in a word processor. Even quite mundane user tasks can involve requirements gathering, specification, design, coding and debugging. In order to account for these experiences, the second proposal of this paper is that almost all major software applications could now be recognized as including programming languages. If this were the case, research into programming could focus on programming experiences independent of language, especially those which result when abstract notation replaces direct manipulation. What is programming activity? The word programming is often used in common speech to describe activities that might seem trivial by comparison to large-scale software application development. People do not in general say they are "programming" their Word document when defining a paragraph style. But many people do say (even on their resumes, I have found), that they have been "programming" in HTML. Furthermore, people say they are "programming" their VCR, their microwave oven, their car radio or their boiler controls. Is there any value in extending our attention to these common uses of the term when we do research into the cognitive demands of programming? If we consider the user experience of marginal programming technologies, as addressed in the previous section, we see that even these mundane activities share many of the same properties. They all have the basic character that the user is not directly manipulating observable things, but specifying behaviour to occur at some future time. In order to address these experiences, the third proposal of this paper is that when people say they are programming, we should not question whether this activity is genuine programming, but instead analyse their experience in order to understand the general nature of programming activity. Cognitive features of programming What are the cognitive implications of this broader domain of programming tasks? The common features of the various programming tools described so far are a) loss of the benefits of direct manipulation and b) introduction of notational elements to represent abstraction. It is possible to relate both of these to relevant topics in cognitive science. Loss of direct manipulation The cognitive benefits of direct manipulation arise partly from the fact that image-based representations mitigate the "frame problem" in cognitive science Such planning is only possible if the scope of effects of a given action can be constrained. In other words there must be a defined boundary beyond which the action will not have further effects. If there is no basis for setting such a boundary, any action may potentially have infinite consequences, and it will not be possible to place bounds on the planning algorithm. This is known as the frame problem. In direct manipulation systems, many constraints on causality are made directly available via the user's perception of the apparently physical situation. This is less true of linguistic representations, where there is no limit on the abstract expressive power of the representation system These considerations lead to the well-known cognitive benefits of direct manipulation In Proceedings of the IEEE Symposia on restoring the state of the representation to that before the action should restore the situation. In programming systems, none of these things is necessarily true. The situation in which the program is to be executed may not be available for inspection, because it may be in the future, or because the program may be applied to a greater range of data situations than are currently visible to the programmer. Where acting on a single situation is concrete (actions have visible effects in the current situation), programming is abstract (effects may occur in many different situations, not currently visible). Multiple effects of an action will be distributed either in space, in time or in both (if two events occur in the same place at the same time, they are the same event). In previous publications, we have described these fundamental non-direct manipulations of programming as "abstraction over time" and "abstraction over a class of situations" Use of notation The second universal characteristic of programming situations is that the program is represented using some notation. This is also a universal characteristic of abstract thought. According to one perspective in the philosophy of mind, concrete action is that in which there is a causal relation between the action and a perceivable state of the world Is there any kind of programming that does not use notation? It would be possible to do programming using representations not usually regarded as notational (e.g. by speaking to a computer, or drawing a picture of the required situation in the world), but these alternatives can be regarded for our purpose as impoverished notational systems. The cognitive benefits of various notational options have been analysed at length by Green with various collaborators in the Cognitive Dimensions of Notations framework Abstraction as a tool for complexity Tools for processing abstractions provide a further benefit beyond those of defining actions in the future, or in multiple situations where the actor need not be present. Conceptual abstractions can also be defined and combined in order to manage complexity. This results from a further confluence of the two primary characteristics of abstract action, indirect effects and notation use. In a simple programming activity such as programming a VCR, the user is defining some abstract behaviour which is not directly observable because it will take place in the future. This is done with the assistance of a simple notationperhaps a display of start time and channel identification. But the user manipulates this notation directly -there is no higher order mechanism by which the user can specify changes to the programme other than those defined directly with the VCR controls. In contrast to this very simple programming situation, more complex situations can be approached by defining changes to the notation itself, so that the user can extend the vocabulary with which he or she will then express required behaviour. An example of this in a domestic context is a sophisticated boiler control (such as those common in Central Europe) in which the user can define one or more modes of operation, then specify that a particular mode should operate at a particular time of day. This makes programming itself more efficient by allowing the user to refer to a new abstraction (the mode) rather than repeating all the notational elements defining time and temperature for every occasion on which that mode of operation is required. Abstraction use in which the user conceptualizes common features of complex behaviour, then formulates notational abstractions in which to express them, completes the range of generic programming behaviours for which we propose a common description of cognitive challenges. In the domain of professional programming, this type of abstraction use is still a very active topic of research. One way of answering the question "what is programming" from a computer science context (proposed by Tony Hoare A cognitive model for abstraction use