(Originally published in M. Yazdani, (Ed),
New Horizons in Educational Computing
Ellis Horwood, 1984. pp 220-235
A slightly shorter version appeared in Computing in Schools, 1981.)
School of Computer Science
The University of Birmingham
(Written while at Sussex University, circa 1983).
The first obstacle to real progress is rapidly diminishing. Very soon it should be possible to buy powerful 32-bit microcomputers with large amounts of memory very cheaply. These will give individual users the power currently obtainable only from much larger and more expensive machines. So problems of memory and processor time will no longer be an excuse for not making systems more approachable by ordinary people.
The second obstacle will remain, unless we can be far more imaginative and adventurous about designing languages, programming environments, operating systems, etc. But old thinking habits die hard, and computer scientists are often more interested in how to design systems about which one can prove theorems than in how to make systems more approachable for ordinary people. Work in Artificial Intelligence is an exception, but until now AI research e.g. into natural language communication, has often been hampered by a lack of computing power, and a lack of understanding of how to make systems easy for novices to use. Nevertheless, some of the languages and program development environments created to support AI research are more suitable for beginners than the more common ones. At Sussex University we are already using such a system, called POP-11, derived from POP2, for teaching absolute beginners. The same system is also used for advanced research. It is sufficiently powerful that most of the POP-11 system, including a sophisticated screen editor, is written in itself. (This makes it potentially very portable.) In fact our POP-11 system is embedded in a larger system, which we call POPLOG, since in includes PROLOG, and also LISP. These languages a powerful screen editor, and a large collection of library programs for teaching and other purposes, are all written in POP-11.
With the new more powerful machines which will be increasingly available we shall be able, and we should try, to provide young programmers with a training which is more suited to the design of serious programs. This requires a language, or more precisely a programming environment, which encourages the development of clear, well structured, programs, and which makes systematic testing, debugging, and maintenance as easy as possible. Increasingly it is programmer time, not machine time, which is expensive.
Unless there is a co-ordinated effort at national or even international levels to look ahead to the needs of the future, there is a real risk that many schools will be stuck with an out of date approach to computer education, namely teaching based on BASIC. This can do permanent damage. I've seen evidence that some children are being turned right off computing by what they currently experience in school. How many of them will subsequently never take another opportunity to give computing a second chance? This and the bad habits taught to the minority who enjoy BASIC hacking leave me wondering whether putting micros into schools at present is doing far more harm than good.
Even if not everyone now can have the most desirable tools, at least more people should be thinking about them, developing and testing prototypes. A top-down approach is desirable. We should not be arguing now about which of the existing alternative languages is best. Rather we need to agree on features that should be present in languages and programming environments used for educational purposes, and then perhaps develop such languages, if no existing languages are found to be adequate. In particular, I want to stress the importance of the environment, that is the editing facilities, the 'help' facilities, the tracing and debugging facilities, the documentation facilities, the library facilities, the ability to share programs, the ability for users to collaborate on programs, and so on. The environment is at least as important as the language, if programming is not to be a real chore. A good environment will encourage the discipline of documenting and cleaning up programs. A poor environment will not.
To provide an appreciation of the sorts of programs and applications that are already possible, and will be more widely available in the near future, beginners need a powerful language with a wide variety of features. Big building blocks make it easier to build more interesting and more useful structures. The language should not only be easy to use for the first few hours. The language, and the general hardware and software environment should go on providing facilities which make learning, program design, testing and development as easy as possible for an increasingly complex and varied range of programs. This will make the use of computers fun and fruitful for far more people than at present.
Here are some proposals, based on experience with a number of different systems, and several years experience teaching non-numerate students and some children. These proposals can be put into effect using current hardware and software technology.
--- this is a test sentence
s([this is a test sentence]) ==>
In the old days, when memory and processor time were expensive, these requirements were serious obstacles. Now they are not.
[A list [ in a list ] of words]
with the syntax of a more conventional language:
A learner should not have to type the latter. For that matter neither should an advanced programmer! The beginner should not even need to know that when she builds and manipulates lists she is essentially making use of binary trees, any more than the person who learns to use a television set needs to learn about transistors, or the car driver needs to learn about spark-plugs. We have demonstrated at Sussex that students can learn to do quite advanced list manipulation by thinking of lists only at a high level of abstraction. The need to know more about the implementation arises only when links are changed in a previously constructed list. By allowing list elements to be accessed by numerical indices we also reduce the cognitive demands. Compare:
list --> [= ?x ?y ==]
Here '=' means 'ignore one item', and '==' means ignore any number of items, while '?' prefixes a variable which is to be given as value the matching element. Compare this with the more conventional
x := front(back(list)); y:= front(back(back(list)));
More importantly, suppose the programmer wants to make a list of all the words between "I" and "you" in a given list, and assign the new list to "verbphrase". here is the pattern-directed structure decomposition in pop-11:
list --> [== i ??verbphrase you == ]
The "==" symbols mean: ignore arbitrarily many list elements. The prefix "??" says that the next word is a variable to be given as its value a list of all the corresponding elements in the original list (the one on the left of "-->").
Compare this with the more conventional:
verbphrase := nil; until front(list) = "i" do list := back(list) enduntil; list := back(list); for element in list do if element = "you" then return(reverse(verbphrase)) else verbphrase := cons(element,verbphrase) endif endfor; error('"you" missing from list')
Programs based on patterns are much easier to understand, much less error prone, and can be much more compact. For instance, having a pattern embedded in a pattern can be equivalent to nested loops in the more conventional languages, e.g.
list --> [ == [sentence == i ??verbphrase you == ] == ]
Here LIST is a list of lists, and it is to be searched for a list starting with the word "sentence". That list is then to be searched for a set of words occurring between "I" and "YOU", and the list of all those words assigned to VERBPHRASE. Try writing that in your favourite language.
Without claiming that the POP-11 syntax is the best that could be devised (and we are open to suggestions for improvements) we do claim that the use of this essentially graphical representation is much more natural and approachable than the kind of representation which most of the more algebraic languages force on the programmer. (Of course POP-11 allows the conventional style of programming when that is required.)
I don't have concrete evidence, but I suspect that most learners will not find it natural to express all programming ideas in this sort of framework, as required by SMALLTALK. It is good just to start with a collection of generally usable data-types and generally useful procedures for operating on them. Whether an instruction is presented as applying a procedure to a structure, or sending a message to a structure may not make very much difference for more sophisticated users. However I suspect that for the beginner the latter may be very confusing. Few people would naturally interpret
3 + 5as an asymmetrical request to 3 to add 5 to itself.
The creation of new procedures at run time requires that the parser or compiler should be available as a subroutine for user programs.
The provision of good debugging tools may also require that debugging aids should be able to treat procedures as objects which can be modified, so as to alter their behaviour temporarily for debugging purposes. Making a procedure produce trace printing is an example.
(Note added 2001: the methods associated with the 'objectclass'
package that is now part of Pop-11 implement this idea, especially in
conjunction with the graphical tools in Poplog which allow asynchronous
event handling. Another implementation of the 'whenever' concept is
found in the Poprulebase package that forms part of the SimAgent package,
The Sussex University POPLOG system combines PROLOG with POP-11, to provide the best of both worlds. [Hardy and Mellish 1982].
But this idea of building on familiar and entertaining 'micro-worlds' can easily be generalised. For instance, students can play with programs which 'think' about the movements of people or animals from one place to another. A database of information can represent the state of the world and be changed by executing procedures. For example, one of our teaching packages (originally written as a project by an undergraduate, then adopted by Max Clowes for teaching) introduces the world of the puzzle in which a man has to get a fox a chicken and some grain across a river, using a boat which will hold the man and at most one other item. Commands are available like
putin([fox]); getin(); crossriver();
This sequence will produce a 'mishap' message announcing that the chicken has eaten the grain. Students can ask for the current database to be printed out at any stage. The syntax is slightly ugly, but it does introduce the idea of applying a procedure, the idea of a list of words, etc. But the syntax is not the main point. Another micro-world involves simulating a hand moving blocks about on a table, making towers for example. However, in this case students are led through the process of building the programs which simulate the movements themselves.
In both cases it is very important that the simulation is not just doing something on the screen or on a real table with a real robot arm, but in a representation of the world, in the computer. For this introduces the idea of a computer which thinks about something, makes plans, tries out plans and strategies. Not only does this introduce very powerful ideas for thinking about how computers can be used, and abused, it also leads to new ways of thinking about how the human mind works. Having a computer control external things which it cannot perceive does not have these advantages. For this reason we have made our turtle create pictures not by doing something on a screen, but by 'painting' a two-dimensional array inside the computer. This can be printed out, but it can also be used as input to other programs which analyse the picture, and produce some sort of description of their structure. Again, students start by using library programs which do the analysis, then later they write their own programs to do this.
Other packages we make available include a program which enables students to type in a simple grammar, e.g. for a subset of English, and then explore its properties either by seeing which sentences it will parse, and what sort of analysis of the structure of sentences it produces, or by having the program generate at random sentences which accord with the grammar. The latter generally shows that the grammar allows far more constructions than the student intended, and trying to control this by extending the grammar can lead to real linguistic insights. Again, the fact that the computer is manipulating the rules for the grammar, presented in a form which is easy for people to read also, helps to indicate some of the power of computing, and raises challenging questions about how people understand language.
I cannot claim that we have come near to exhausting the potential of this approach. If students come to us for only one term, there is no time for the majority to explore more than four or five such packages, though the very best students manage to achieve far more than even the average ones. There is probably no right set of packages -- different teachers, different environments, different age-groups, can all be accommodated with different sorts of toys. Indeed, it is probably important for teachers not just to import someone else's packages, but to have direct experience of building their own, so that they have a deep understanding of the problems the students will encounter when they try to construct their simpler versions, or when using the package produces unexpected behaviour.
The presentation of these teaching packages in the POPLOG system makes very heavy use of features of the environment described above. The editor is used by the students to read a library file which gives instructions. It is also used to type in commands. The incremental compiler is used to compile appropriate library files, and also to compile and execute commands typed in by the student. Powerful list manipulating and pattern matching facilities make it relatively easy for the teachers to build interesting programs, and for the students to do likewise. The mail system and other facilities allow users to help one another, to share files, to request help from the teacher, etc.
The development of computing languages has shown a steady move towards more and more sophisticated virtual machines, vastly improving the ease of communication between person and computer. There is no reason to believe that existing programming languages have achieved anything close to the maximum level of comprehensibility. Much research is needed into the reasons why it is so hard for all but a small proportion of the population to become good at writing programs. Perhaps this will lead to a collection of new constructs for programming languages. In particular, there is no reason why at least for the non-expert programming languages should not be far more closely modelled on natural languages. Why shouldn't the programmer be able to say:
Make a list of all the words between "I" and "you" and call it VERBPHRASE.
instead of having to use some artificial and unfamiliar language? Of course natural languages are often ambiguous and imprecise, and that means that communication has to be two-way, with the hearer free to ask for clarification and disambiguation. Similarly, programming could be much more of an intelligible dialogue with the computer. For professional programmers writing programs to be used by others, it is very likely that artificial languages will remain superior. But for beginners and for those who wish to use computers as non-specialists, it should be possible to use a more familiar and natural language. It is not easy to give a computer the ability to understand unrestricted English, but work is progressing, and it shouldn't be too long before much more friendly systems are possible than anything currently available. Of course, they will make heavy demands on processors and memory, but that should not be a problem.
One of the implications of these ideas is that beginners need very sophisticated systems, not simple systems. It might be thought that different systems are needed for advanced users and sophisticated programmers. As a teacher, I have found I prefer the language I use for writing complex programs to be essentially the same as the one I use for teaching, even if the students only learn about a subset of the language. Some of these features would not make much difference to absolute beginners, but the more advanced pupils (aged about 12 upwards) would be able to benefit. Moreover, teachers would find such a language much better for writing teaching programs than BASIC and other common languages. And our experience shows that even absolute beginners benefit from having good list-processing facilities from day one.
This collection of desirable features will probably not make much sense to someone whose experience so far is restricted to primitive languages like BASIC, FORTRAN, PASCAL, and assembler languages. I sometimes find that pupils with such experience have more difficulty learning to use powerful techniques, like recursion, than beginners, who have no previous experience of computing. Going the other way, from a good language to a poorly structured one is easier, though very annoying!
I am worried that our schools will produce pupils who have got used to a style of programming which is most unsuited for the design of complex programs, and that such pupils will find it hard to absorb more powerful concepts and techniques, like people used to Roman numerals resisting the move to Arabic notation. (After all, they'd probably argue, 'I II III' is clearly superior to '1 2 3'. Never mind the problems of expressing '562,349' in Roman numerals!
I am also worried that instead of helping lots of children to approach computing, the present practice of putting very limited microprocessors, with primitive languages, into schools will not only teach the gifted few bad programming habits, but will permanently turn the ordinary majority against computing. They will find it boring, frustrating and difficult, and, having been permanently turned off computing, may therefore not take up the opportunities to learn to use much better systems which will be available in a few years. Perhaps it would be better to keep micros out of schools until far more approachable systems can be provided! I wonder how many micro-computers eagerly sought as Christmas presents not long ago now lie unused in cupboards because they are so difficult and frustrating for the ordinary user? Alternatively they may be used solely for the purpose of running game-playing programs of a type which may teach some manual and visual skills, and little else.
The software knowledge to design and implement better languages is now available. Machines with the power to make such languages cheaply available will soon be on the market. A co-ordinated initiative, with co-operation between government, manufacturers, and schools could put really powerful and effective computing resources at the fingertips of all children within a few years.
But I fear this will not happen because too many people are too content with what they already know and love. There is plenty of evidence already that in the world of software it is not necessarily the fittest which survives.
Readers may find it useful to consult
Seymour Papert, Mindstorms, Harvester Press, 1980.
'The Poplog programming system'
Cognitive Science Research Papers, No. 3, 1982, University of Sussex.
C.S. Mellish and S. Hardy
'Integrating Prolog in the Poplog environment'
Cognitive Science Research Papers, No. 10, 1983, University of Sussex.
The Pop-11 language is part of the Poplog system, which was ported to linux
around 1998, available free of charge as open source, containing all the above
teaching facilities, here;
A subset of the Teach files can be browsed here:
A sample of video presentations demonstrating some of the facilities of Pop11
and Poplog can be found in