Written by David Tebbutt, Personal Computer World 03/89 - scanned
Tim O'Shea and Thomas Green are re-examining the problems of language unfriendliness, especially with regard to object orientation and the Smalltalk language. David Tebbutt met them at Xerox EuroPARC in Cambridge, from where their work stands to effect all computer users.
Tim O'Shea divides his time between the Open University and Rank Xerox EuroPARC, the UK end of the Xerox Palo Alto Research Center in California. As well as being Professor of Information Technology and Education at the Open University, O'Shea has been associated with Xerox PARC since 1972. In fact, he spent the whole of 1986 with the Smalltalk group in Palo Alto. He was there to help them understand why object-oriented programming is so difficult to learn.
Despite Smalltalk's five editions and a number of other object oriented languages, such as the LOOPS extensions to Lisp, O'Shea says that few large applications have yet been written using any of these languages.
Although Smalltalk is based on a small set of core concepts, the attrition rate for newcomers to object oriented programming is very high. People start to learn and then simply drift away. O'Shea says they seem to get indigestion. He has noticed that people learning Prolog have similar difficulties. Others have suggested to him that if people become used to programming in other languages, perhaps their heads have become damaged in some way. O'Shea hasn't found this to be true. In fact, many programmers who have successfully learnt an object-oriented language claim that they were most helped by previous knowledge of languages such as Cobol or Lisp.
THE STORY OF OOPS
The idea of an object-oriented approach to programming began just after the Second World War, when Kristen Nygaard was faced with the problem of constructing large-scale simulations of real-time processes. He observed that each object to be simulated had its own behavioural characteristics. A girder in a bridge, a capacitor in an electrical circuit, even a mere wire behaves in certain predictable ways to external events. The basis of object-oriented programming is to wrap up the behavioural repertoire of an object and condition this package to respond only to those stimuli which affect it.
Messages, or external stimuli, wash past, but the only object which responds is the one which recognises a message as meeting its own requirements. An object will absorb the message, carry out whatever activity the message stimulates, and pass any results back out into the wider world in the form of more messages to be acted on by other objects.
The above description looks like a recipe for anarchy, and any system constructed in such a way would Tim O'Shea: turning spaghetti-type ideas into metaphorical lasagne soon become unintelligible to both its author and anyone else involved in its development and maintenance. Such programs and data clearly needed to be organised. In a large scale program, you might even be talking about millions of objects.
This need to organise led to the concept of classes of objects. To pursue the real-world example mentioned earlier, at the highest level, you could talk about physical objects, electrical objects and so on. Within the electrical class, you might have capacitors, resistors and batteries. Then, within batteries, you might end up with specific devices, such as 6v batteries. In the 1960s Nygaard and a colleague embedded these object oriented concepts in Simula, a language they designed as an extension to ALGOL 60.
Later, Alan Kay came along in search of a language for his Dynabook. He knew that an object oriented language would be right, but he wanted a graphical interface. He wanted to depict a thing on a screen and show changes as they happened. Simula was taken and given a graphical environment.
This wasn't good enough, so Kay then got to work on Smalltalk, the first version of which (Smalltalk '72) was mocked up in Basic. This was aimed at children but it proved to be difficult to use. The programming environment and the number of intrinsic classes kept growing, which made the language increasingly difficult to learn and understand.
The Smalltalk development paralleled that of Lisp. In fact there was a lot of movement of people between the Smalltalk and InterLISP development teams. Object-oriented programming capabilities were added to Lisp while Smalltalk grew to the extent where it became a full programming environment, complete with browsers, tracing facilities, editors and all the other tools which programmers need.
Because the Smalltalk environment is homogeneous, it is possible to change menus, editors and so on using Smalltalk itself. The buyer of a Smalltalk application has to buy everything, the programming environment included, which is one of the reasons why Smalltalk has yet to achieve a wide acceptance.
When memory was expensive, it was simply not fair to expect users to have to buy the entire Smalltalk environment when all they needed was the application program. It was also regarded as unwise to give inexperienced users the ability to alter Smalltalk, which would possibly have fatal consequences.
LEARNING PROBLEMS
In 1986 O'Shea embarked on his study of learning difficulties. He spoke to the designers of new object oriented language dialects. He spoke to Smalltalk teachers and their students. He conducted clinical interviews with people who were having learning difficulties, and he also had students filling in report forms on their learning progress. He was especially interested in their observations about when confusion arose and how it was cleared. The feedback from these questionnaires also helped direct his questioning. He studied large chunks of Smalltalk code to see what constructs were actually used.
Everyone except the dialect designers agreed on sources of difficulty. O'Shea commented, 'This is normal.' (It's outrageous that programming language designers have the arrogance to stand by poor design decisions which increase the workload, prolonging the learning process for generations of programmers.) Anyway, the results of the study confirmed that learning difficulties were experienced and that some Smalltalk concepts were very hard to follow. The main conceptual difficulty concerned 'metaclasses', which are generated automatically by Smalltalk as a class is created. They parallel and sit behind each class and are used to initialise the class, to define its starting behaviour. O'Shea gave the example of a tennis ball. Characteristics such as size, location, colour and the fact it bounces have to be defined before it can do anything. Because the metaclass lies outside the official class system and doesn't obey the same rules, this makes the concept hard to learn.
Another area where students have problems is in the hierarchy. As we've seen, the metaclass doesn't fit very well, but then neither do certain types of inheritance. Returning to the example of a capacitor, this may be defined as an electrical object. It may also be regarded as a physical object, so it has mixed parentage, borrowing characteristics from different parts of the hierarchy.
Under such circumstances, the class structure is no longer a pure tree. Even so, the capacitor example is reasonably easy to understand. Life gets more complicated when you start to create new methods (these are the ways of doing things which sit inside each class, rather like subroutines in conventional programs) which can be made to override methods higher up the hierarchy, or when you bypass these overrides, which you can do with certain non-standard forms of inheritance. The end result, if you're not careful, can be a real tangle, not so much for the originator of the code but for those who follow.
One of the theoretical benefits of object-oriented programming is that objects may be re-used elsewhere, either in the same program or in another. Problems arise, though, when the original programmer wants to employ multiple inheritance or borrow behaviour from higher up the tree. When later programmers come along and decide to re-use a definition, they may find themselves inheriting behaviour from some unexpected places. The newcomer cannot understand the definition properly until they familiarise themselves with its other connections.
An alternative would be to abolish all forms of non-standard inheritance and keep the tree pure. Smalltalk will still allow you to redefine methods lower down the tree; it would just mean that the new class would have to contain a copy of the original method as well as the new adaptation. This would lead to more coding but a cleaner and more understandable program. Similarly, the removal of multiple inheritance will mean repetitive coding to achieve the same result, but it would make for a pure, easily understood tree structure.
Other learning problems come from the syntax of the language. Giving capital letters significance is one. O'Shea believes that they shouldn't have meaning. Mixing infix and prefix notation is another. The sheer size of the environment is another difficulty.
O'Shea talked of 200 classes and 5000 methods in which you simply get lost. What's more, he doesn't think it's either right or feasible for a programmer to try and envision the entire system. But that doesn't stop them trying, and experiencing learning difficulties as a result. O'Shea gave the example of a man he met in California who had been a professor of physics. This man was a very good programmer and actually wrote operating systems in C, on a freelance basis. When O'Shea went to visit him, the man had bought Smalltalk and was trying to get to grips with it. Failing to understand it from studying the literature, he printed out the entire system and spread all the methods out round his house. He had paper on just about every available surface, including the piano and the sofa and, strung between them, bits of cotton to keep track of the relationships. 'It's wrong to imagine that you can understand it,' says O'Shea. And, since we're used to understanding our programming environments, this is one of the reasons why Smalltalk gives us the indigestion mentioned earlier.
FINDING SOLUTIONS
EuroPARC is concerned with finding ways around these learning problems. The choices which face O'Shea at the moment are: to redesign the object-oriented languages (by removing metaclasses, or by removing the object-class distinction, for example); to improve the environment (perhaps by including a cartoon strip animation which lets you 'see the works'); or to change the way the subject is taught.
For now, he has chosen the first course of action. He is taking a knife to object-oriented systems to empirically test the effects on the learnability and understandability of the systems. He doesn't believe that anyone knows enough about the psychology of the subject to be able to predict the outcome of such surgery. He is making brutal changes removing metaclasses and even classes. He's performing lobotomies to see what happens. He calls this his 'brute elegance' approach.
His aim seems to be to encourage language developers to think differently about their work. Rather than keep adding features and functionality, he would like to see them pause and take stock of the effects of increasing complexity. He'd like to see the language developers concentrate their energies on retaining the power while making the languages simpler.
While O'Shea was at Xerox PARC, he and Alan Borning from the University of Washington collaborated on a paper called 'Deltatalk: an empirically and aesthetically motivated simplification of the Smalltalk 80 language'. In it, they identified a small set of changes which would make Smalltalk easier to learn and easier to use. Among the recommendations, they suggested that metaclasses either be removed, or a way be found to illuminate their creation and operation.
On system size, they suggested introducing some form of layering through the use of modules. They reported that many students use a 'spaghetti' metaphor for the existing system, so they proposed a shift to 'lasagna'.
They also advocated changes in the significance of capital letters, the introduction of underline as a valid character, and more consistency in the tone and content of error messages. They also came down in favour of single, rather than multiple, inheritance.
O'Shea thinks it was very brave of Adele Golberg at PARC to let 'someone so critical and grumpy' into PARC to criticise their Smalltalk baby. The fact that he's still involved leads him to believe that he's a very useful piece of grit in the PARC oyster.
GREEN'S REVOLUTION
Thomas Green spends about 80% of his time at EuroPARC, the rest at the Medical Research Council's Applied Psychology Unit in Cambridge. His role is to understand the issues which control human understanding of programming languages and other notations. He is also involved in designing programming environments to complement programming languages.
Green claims that all forms of notation display some information very clearly while hiding other information. He uses the term 'notation' deliberately, to show that he's interested in a program's structural features rather than its semantics.
Some notations which might be very good for one purpose will be hopeless for another. Green gets mad at people who ask him questions like 'Is Pascal easy to use?'. He always asks 'for what particular task?' After all, the language might be very readable but not very easy to write in the first place. Equally, assembly language might be easy to write but, unless it is heavily commented, it is almost impenetrable later on (even to its author).
In his research work, he has found that programs are developed in a sequence which is quite different from the order of the text which appears on the page. He credits Robert Rist, of Yale University's Department of Psychology, with the example of a small piece of Pascal code shown below.
This is a very simple example, but it makes the point and reveals much about the way in which a programmer works. On a grander scale, programmers insert and stitch together program components of different sizes. Second thoughts force them to amend and move bits of code around, perhaps changing other parts of the program to maintain consistency.
Green tries to tie together the interests of the author with the interests of those who follow. A good programming support environment, for example, might be able to overcome the frustrations of having to write program code in a particular way.
NEW DIMENSIONS
To give a coherence and structure to his thinking, Green has identified a number of dimensions upon which to assess notations, from the point of view of both writing and comprehension. He is now applying these criteria to a number of languages and other notations (such as spreadsheets and word processors) to see how they stack up. One of his themes is 'consistency'.
He regards this as a very important attribute to any notation, but is surprised how often he runs into inconsistencies. He gave one example (which I'll modify to make it easier to follow) of a text editor in which Ctrl signified a small movement and Alt signified a large one. Thus Crtl-F meant 'go forward one character' and Alt-F meant 'go to the end of the line'. Why then did the same program use Ctrl-V to go down a page and Alt-V to go up a page?
Consistency is all about how the set of tasks that are in your mind map onto the actions required to perform those tasks. The better the correlation, the easier a notation is to learn and use. A large, but consistent, programming language is much easier to learn than a small inconsistent one.
Another theme is 'role expressiveness'. Or: how easy is it to read back from the documentation what was in the author's head? Green has tried a number of psychological experiments on this one. Not surprisingly, assembly language rates very poorly, as does Prolog. Pascal isn't too bad, though, because the end result has a clear structure.
He also refers to viscosity, or the lack of it, as an issue. (The more viscous a notation, the greater its resistance to change.) Viscosity increases when constraints are placed on the physical arrangement of components. In Pascal, for example, you are obliged to place a procedure before any reference to it. This means that certain program changes will necessitate changes which are needed simply to meet the constraints of the language. Lisp programs, Prolog programs and spreadsheets impose no such structural constraints.
He talks of 'right to left constraints' which refer to the fact that the written order of things is not necessarily the same as the thought order. In fact, the top-down design of Smalltalk can force the programmer into making premature decisions. The problem is that no-one gets it right first time and later amendments are more or less complicated according to the 'right to left constraints' of the notation. Anything which helps decouple the order of writing from the order of thinking is of great help.
Many notations have asymmetric or hidden pointers which make life very complicated for those trying to understand what's going on. Even since PCW started (and before that), people have argued the cases for and against the use of GOTO. Green does not favour GOTO because it has no ComeFrom: it is asymmetric. A spreadsheet has plenty of references to other cells in the matrix but those cells give no clue about what cells refer to them. The pointers are there, but they're hidden. This can make changing a spreadsheet a worrisome affair. A simple cross-reference window would solve the problem at a stroke. Other criteria by which Green assesses notation are 'slip-proofness' or how easy is it to make mistakes. He cites Smalltalk's use of capital letters as a good (that is, bad) example. He talks of the interleaving of program components which can lead to difficulties in understanding, caused by the reader having to use large amounts of his or her own working memory to keep track of all the strands. At least the object-oriented approach means that each object is usually self-contained, and can therefore be understood without interference from other bits of code.
By classifying and explaining the criteria by which a notation may be judged, Green is hoping that people will be able to think more clearly about what sort of design is appropriate for their needs.
Applying his thinking to Smalltalk, Green is exploring the possibility of avoiding the use of classes, the idea being to create objects which can then be used as prototypes for new objects. His role is to figure out what new problems would be revealed by such a change in approach.
If the class inheritance system is abandoned, a method will be required of finding a particular piece of code. Perhaps the answer is to let the programmers build in their own links between related objects. Or maybe replace the class structure with something less strict. Or maybe introduce a query-by-example database of objects.
CHALLENGE
Green and O'Shea are being paid to challenge the design decisions of the past and to try and find ways of improving the learnability and usability of programming languages and their environments. Like the Xerox inspired WIMPS, one day we shall all be the beneficiaries of their efforts.