Are you trapped by the “Computer-thinking” box

I have just had a message asking if there was a manual for MicroCODIL, and whether the source code is available and in my reply I said:

Of course there is a manual for MicroCODIL and, as most of the code is written in BBC Basic I effectively released most of the source code when the trial version was produced for a BBC Microcomputer in the 1980s – when more than 100 copies were distributed, in most cases to schools. As the BBC Micro was very much of a cult machine there are always working BBC systems for sale on ebay.

The way to learn to use and understand MicroCODIL is to play with it – which is, in effect, the way a child learns about the world. While there is a detailed manual MicroCODIL it is accompanied with a whole range of demonstration applications and it was these demonstration applications which so impressed the reviewers who liked it. The difficulty is that the more someone knows about conventional computer systems the harder it is for them to understand the novel features of the CODIL approach.

The important thing to realise is that we are all mentally trapped, to some extent at least, by the way life has taught us to think about the world. Most people who are reading this blog will have been taught that learning general rules is useful because we cannot possibly learn everything there is to be known. This approach underlies the scientific method – where success is judged by the power of the general rules one discovers. It is the keystone of modern computers – which depend on humans to create algorithms that can be programmed.

If you are reading this you will inevitably have been affected by “computer-think”. Your job may depend on your ability to design algorithms and you take the power of the stored program approach for granted. On the other you may have had problems in following the information technology classes at school, but love using systems which are based on computer technology. As a result you take the miraculous black box for granted – never questioning what goes on inside – except to curse when it doesn't work. And if you are older you may simply reject computers as something you will never understand – and have no wish to even try to understand. Whoever you are, if someone sits you down in front of a screen, with a keyboard or other input device, you will automatically enter “computer-think” mode, and make assumptions as to what to expect.

CODIL is an attempt to build a tool which break away from this way of thinking about information. The basic philosophy assumes a bottom-up approach to processing knowledge – in effect starting from a new-born baby situation about knowing nothing, not even what tasks you might end up doing, and building upwards from total ignorance. A major design assumption was that if the system was to work symbiotically with humans on non-trivial open-ended tasks it must be a white box which keeps no secrets from its human “master.” In “computer-think” terms the symbolic assembly language used by the central processor of the CODIL system is that same friendly language that the human uses to interact with it. This means that the computer can always tell the user what it is doing in the user's own language.

The problem I have is in describing the CODIL system to people who take “computer-think” for granted. Let as consider a simple analogy:

Let us image that I have invented a rowing boat which will enable you to cross a river wherever you want – but the only known way of crossing a river before my invention was to build a bridge. You are a bridge-building engineer (who of course has never seen a boat, because they have not yet been invented) and you approaches me because you have heard what I am doing and you think it would be useful to have a bridge which will allow you to cross wherever you want. You therefore ask to see the design plans for my boat, together with user instructions. You looks at the plans, and being an engineer you can see how the boat is constructed – but clearly it is useless because it is too short to reach from one side of the river to the other. As for that crazy manual describing how to row the boat – this is obviously useless – as once a bridge has been built you just walk across – and don't need oars, much less a manual! The answer to the problem is not to give you the paperwork but to take you down to the edge of a river, sit you in a boat, and row you across to the other side.

Computer-think is nothing new. One of the first books looking at the psychology of computer programming noted that if you taught the then new language PL1 you found that students who had previously written programs in COBOL used PL1 as if it was COBOL. If they were Fortran programmers they tended to use the subset of PL1 which most resembled Fortran. On the other hand novice programmers had no such inbuilt inhibitions .

My research on CODIL has the disadvantage that it was carried out in the Computer Science department of a minor technological university and was surrounded by people who saw conventional computing was the only way forward. I had virtually no direct access (in the 1970s and 1980s) to people who were unaffected by some aspects of “computer-thinking.” I remember one Computer Science student deciding to do a project comparing CODIL with COBOL. He came to me excitedly saying that he didn't think it was worth his while doing the application in COBOL because it was so much easier in CODIL. I looked in horror at what he had done – in that he had used CODIL as if it was a COBOL interpreter – which may have been easy – but which provided none of the dynamic flexibility the CODIL offered, and none of the rigid control that accountants would have insisted on in a commercial task which handled money transactions!  Instead of designing a system to model the processing of customer sales record he had designed a system to model the way programmers model the application.

Another example is particularly relevant. In the late 1970s I was approached by a computer journalist who wanted to know more about CODIL. I showed him some of the applications including several involving the storage and retrieval of poorly structured information, plus some powerful artificial intelligence type examples of what the system would do. He never published the article but a year later the University was approached about a joint commercial project. A copy of the program was passed to him to assess the difficulty of transferring CODIL to an early PC. He showed no further interest in the project but soon after he started selling a software package called Superfile which captured a significant part of archaeological data base market in the UK. Basically Superfile used the file handling approach I had used in CODIL (which on its own was not particularly unique) and had ignored the powerful control features, replacing them with a rather unimaginative conventional interface. I later heard that my program had been passed to a computer geek who, of course, had never seen what the system could actually do, and couldn't understand the control structure - so he left it out! If there had been proper collaboration Superfile would have been very much more powerful, and the association with a commercially successful package would have made it far easier for me to attract funds for further research. We could have had something as logically powerful as MicroCODIL – but with the ability of handling very much larger volumes of information – together with someone who clearly had the marketing skills I clearly lack. 

On looking back on the project's history I can see that even my own thoughts were limited by computer-think. The idea only started because I had been working on complex management information processing tasks manually and then moved to the computer industry to be faced by a complex management information processing task. I just transferred my manual approach because I didn't know that that wasn't the way that the establishment believed computers were supposed to be used. A different, more imaginative, employer liked the ideas and the earliest CODIL research started with the idea of modifying the central processing unit in a computer such as the IBM 360 and as a result included a lot of “computer-thinking.” Virtually all the important design improvements since have been due to the elimination of some aspect of stored program computer technology which had sneaked into the design. The recent “Eureka” moment was to realise that, if CODIL was to provide a possible brain model, one needed to forget the idea that information was held in a clearly defined memory location!