Conclusions

Some of the articles described above, and many of the others I have read, were written in the early to mid 80's, so there has been plenty of time for the ideas they have expressed to be implemented in commercial programming packages. However, the penetration of these packages into the marketplace has been minimal at best. Clearly there is some factor inhibiting the use of such environments by mainstream computer programmers.

The environments that have been produced seem to express programs in an extremely inefficient way. In the paper written by Stelovsky et al. [21], one screen shot shows a program simultaneously represented as text and as a parse tree (see Figure 2.3). The parse tree representing just three lines of code takes up a sizeable proportion of the screen. A similar problem occurs in Rogers' paper [17], where a relatively simple program takes up a whole screen (see Figure 2.2). On the other hand, programs such as SeeSys [1] and PLUM [15] manage to display overall views of a program, but at the expense of ignoring the actual names of the functions of the program.

Furthermore, these environments display programs in a way that I, at least, find highly non-intuitive. It is important, when considering ``intuitiveness'', to distinguish your own prejudices from the genuine suitability or otherwise of a particular representation. Certainly, after several years of programming, I would be hard pressed to change my mode of thinking to a purely graphical representation. However, I believe that the standard, language-based methods of expression have a natural part to play in the expression of computer programs. Language is the means we usually use to give commands to each other, so it is only natural that we should use language to give commands to a computer. This model may only be valid for small-scale ideas, but when you are talking about small scale ideas, it is quite appropriate.

It is only when you start to talk about larger scale ideas that graphical means of expression start to become useful. This is where I think Rohr's model becomes quite useful. He suggested that people need a physical picture of a large system because that is the only way they can efficiently store all the details of the system in their mind. If you are constantly flicking back and forth through code, such a picture can take a long time to build up. This is why, in my project, I plan to use a combination of text for conveying the internal structure of a function, and graphics to represent the relationships between functions. I hope that this will provide an intuitive way of conveying information for a modern programmer.

Matthew Exon 2004-05-28