| Psychology of Programming Interest Group |
![]() |
![]() |
||
|
|
PPIG 1999 |
11th Annual Workshop 5-7 January 1999 Computer-Based Learning Unit, University of Leeds, UK |
Paper |
University of Joensuu, Department of Computer Science
Jorma.Sajaniemi@Joensuu.Fi
cs.joensuu.fi/~saja
Extended abstract submitted to PPIG 1999
Programmers' tasks are manifold including program creation, comprehension, debugging, modification etc. The corresponding cognitive processes are not well known but it is clear that programmers utilize many kinds of information about programs in these tasks (Davies, 1993; Green & Navarro, 1995; Littman & al., 1986; Pennington, 1987; Soloway & Ehrlich, 1984; Wiedenbeck & al., 1993). Computer programs are large and complex objects and include a huge number of details. Even when working with miniature programs people are unable to keep all important details in human working memory but must use external devices such as text editors to make notes for further actions (Green & al., 1987).
With real size programs the limits of human working memory form a limiting barrier to programmers and they must continuously refresh and rebuild parts of their mental representations needed in their tasks. This rebuilding starts from the notes they have previously made and from the physical representations, usually the program text, provided by the programming environment. The ability to abstract high-level information from concrete program code has been found to be essential to the performance of programmers working with program modification tasks (Holt & al., 1987).
But all parts of mental representations do not obey the order, form and immediate content of program text (Green & Navarro, 1995; Wiedenbeck & al., 1993). For example, the overall structure of a program forms one essential part of program representations but it cannot be easily seen from the program code itself as the important lines that drive the representation are dispersed around the program. Similarly, the way a certain variable is used in the program can be found only by searching for all the occurrences of the variable. The normal program text representation is all that a compiler needs but humans need multiple representations, or views, of the same program to support the construction of different aspects of mental representations. For example, Meyers and Reiss (Meyers & Reiss, 1992) have shown that programmers' productivity can be improved by offering them multiple views of the same program.
Pennington (1987) has proposed that programmers extract five types of program information: control flow, data flow, function, state, and operations. Green (1997) has discussed the connection between these types and programming language notations using the match-mismatch conjecture (Gilmore & Green, 1984) as a starting point. He concludes that the type of information programmers extract first depends on the nature of the notation, and that we need to improve access to those types of information that are 'upstream', i.e., not revealed by the notation.
The method proposed in this paper is a step towards the direction proposed by Green. We give programmers an opportunity to utilize multiple editable views of the same program. In other words, the system described in this paper is capable of representing programs in various notations supporting various types of information. Moreover, programs can be edited through most views enabling programmers not only to extract information in multiple notations but also to fully work in these notations. As a consequence, it becomes almost impossible to say which of the notations is the 'right' one, i.e., obeys the syntax of the programming language as understood by the compiler. Thus, the role of the programming language changes from a syntax definition to a more semantic description.
[ top ]
We have implemented a program editor framework, VinEd (Sajaniemi & Ikonen, 1998), that is capable of showing multiple editable views of programs. An optimal set of views is, however, beyond current knowledge of program representations and program comprehension process. It may even be impossible to define any representation that every individual can call sensible, and views probably need to be defined according to the environment and background of the programmer (Shneiderman & al., 1986). This problem is solved in VinEd by letting programmers define their own views and add them to the system. As programmers are programming experts they are able, and supposedly also keen, to create supporting programs that construct views that they feel to be helpful for their tasks. VinEd is shipped with some ready-made views for some programming languages but users are supposed to add their own views.
In VinEd, a view can be any text obtained by applying some transformer program to the original file. As the output of a transformer is text (and not a graphical representation), programming new transformers is relatively easy. If a reverse transforming program is also given, files can be edited (and not just browsed) in the view. For example, the list of all function names in a program facilitates comprehension of the program by showing structured information and the underlying design (Shneiderman & al., 1986). A Pascal programmer can easily make a short program (using a single line UNIX shell script consisting of a call of the grep command with the result piped to a sed command) that makes such a list for his or her own programs (though the solution in the general case is somewhat more tedious). Thus he or she can see the list in a view window with the program text in another window. Even the reverse transforming is simple in this case and hence the programmer can change the name of a function in the function name list, and the system will automatically apply the reverse filtering and thus change all occurrences of that name in the program. Views are updated automatically so that they reflect all the time all editing operations made so far.
It is clear that more powerful views are also needed. An example is the variable-oriented view of programs suggested by Sajaniemi & Niemeläinen (1989). In this view, occurrences of each variable are collected together to give a better understanding of the roles of variables in the program. Once a program that creates such a view is written, it is straightforward to use it in VinEd.
To start editing a program text file, the user opens the file and asks for at least one editable view to be created. The user can use a built-in editor or a standard editor like vi or emacs. In Figure 1, the two large windows show two views of the same program: one with the built-in direct view editor (with the name "Direct (Proportional font)" in its title bar) and the other using vi editor in a VinEd editor window. Further, the view in the lower left corner shows the names of all functions in the program, and the view next to it shows all unsaved changes as produced by the UNIX diff command. Although the diff view contains a small fraction of the program only, it can propagate changes back to other views by recreating the whole program text with the patch command.
VinEd extends the notion of a view to any representation that can be obtained from the original program. As a consequence, it is possible to create views that do not allow editing. A non-editable view can be as simple as the list of all function headings, or a result of a complicated operation like compilation or version control check-in operation. Thus VinEd can be easily extended from a mere editor to include a complete set of software engineering tools.
Programs are written using programming languages that make some information of the program easy to extract but hide other information so that some mental efforts are needed to find it. By offering various views to the same program, VinEd helps programmers to extract many types of information. The notion of editable views even forces us to reconsider the concept of a 'programming language': if a program can be edited in a number of different views, shouldn't we consider all these views equally good representations of the program? And isn't the 'original' representation just 'machine code' intended for compiler use? So, maybe a programming language should be treated as a definition of the set of programs that can be described - and not as a definition of the only allowable notation for the programs.
[ top ]
(1993) The Structure and Content of Programming Knowledge: Disentangling Training and Language Effects in Theories of Skill Development Int. J. Human-Computer Interaction 5(4) 325-346.
(1984) Comprehension and recall of miniature programs Int. J. Man-Machine Studies 21, 31-48.
(1987) Parsing and Gnisrap: A Model of Device Use In: Olson G. M., Sheppard S., Soloway E. (eds.) Empirical Studies of Programmers: Second Workshop, Ablex Publishing Corporation, New Jersey, 132-146.
(1995) Programming Plans, Imagery, and Visual Programming In: Nordby K., Helmersen P., Gilmore D. J., Arnesen S. A. (eds.) Human-Computer Interaction Interact'95. Chapman & Hall, London, 139-144.
(1998) Cognitive approaches to Software Comprehension: Results, Gaps and LImitations Extended abstract of talk at workshop on Experimental Psychology in Software Comprehension Studies 97, University of Limerick, Ireland.
(1987) Mental Representations of Programs for Student and Professional Programmers In: Olson G. M., Sheppard S., Soloway E. (eds.) Empirical Studies of Programmers: Second Workshop, Ablex Publishing Corporation, New Jersey, 33-46.
(1986) Mental Models and Software Maintenance In: Soloway E., Iyenger S. (eds) Empirical Studies of Programmers. Ablex Publishing Corporation, New Jersey, 80-98.
(1992) An Empirical Study of Multiple-View Software Development Software Engineering Notes 17(5) 47-57.
(1987) Stimulus Structures and Mental Representations in Expert Comprehension of Computer Programs Cognitive Psychology 19, 295-341.
(1989) Program Editing Based on Variable Plans: A Cognitive Approach to Program Manipulation In: Salvendy G., Smith M. J. (eds.) Designing and Using Human-Computer Interfaces and Knowledge Based Systems. Elsevier Science Publishers, Amsterdam, 66-73.
(1998) VinEd - A System for Program Manipulation through User-Definable Simultaneous Views Software - Concepts & Tools 19(3).
(1986) Display Strategies for Program Browsing IEEE Software 3(3) 7-15.
(1984) Empirical Studies of Programming Knowledge IEEE Trans. on Software Engineering SE-10(5) 595-609.
(1993) Characteristics of the Mental Representations of Novice and Expert Programmers: An Empirical study Int. J. Man-Machine Studies 39, 793-812.
[ back to PPIG 1999 programme ] [ top ]