History of CODIL

A Short History of CODIL
[Draft under construction]

[See separate page for publications


Introduction
I am sure that everyone reading this will have read books on some of the great success stories of Science, but they only tell you one side of the way that science works. There is far less written about the failures - the research projects that were unsuccessful - and why they failed. Where failed projects have come to the public attention this is usually because there is significant publicity of spectacular claims which are later shown to be unjustified, for instance cold fusion, or very expensive projects, usually connected with space exploration, end in spectacular technical failures of the equipment. There are no well known published accounts of why projects which failed to make the headlines failed, and it is very easy to assume that they failed because they were scientifically unsound.
I was the prime mover in such a failed project which started by accident in 1966 and which I finally aborted in 1988 as a result of stress due to a family tragedy plus exhaustion and complaints about my failure to get research funding. All the extensive documentation was stored in my garage and I did my best to forget about an unfortunate experience until recently. Then two things happened.
One was a talk I gave in 2010 to a local U3A group on the early history of computing and how innovative ideas were brushed aside in the rush to exploit the technology. The other was that my son pointed out that when I passed on he would have no option but to call in someone to clear the vast quantity of papers stored in the house but to call in the house clearers and unless I had already made arrangements it would nearly all end up in a skip.
This got me thinking. It is widely accepted that in Science exceptional claims need exceptional evidence, and the ideas I was researching could well be considered exceptional in that they questioned the foundations of a major area of technology.
This raised a number of questions:
  • Was the failure due to my failure to shout loudly when I was being cautious because I knew that much more research was needed to produce "exceptional evidence,"
  • Was it due to failings in the peer review system for both publication and funding when the underlying idea was counter-intuitive when seen from an establishment viewpoint,
  • When someone is working on a blue sky project how far are they constrained by environment in which they are working, and the presence or absence of a supportive social network.
My first reaction was to write a book looking at the lessons that could be learnt on why the project failed - but old age means I no longer have the mental energy to do this in a reasonable timescale to the standards I felt appropriate, and I decided a better way forward would be incremental publication online, via a blog.  This allows me to feel the water by making information available and responding to any reaction. If no-one is interested I can call in the skip myself and that's an end of it. If the history of the project is of interested to anyone (perhaps as part of a Ph.D. in the History of Science) the papers are of some value. On the other hand there may be people out there on the net who feel that my ideas are worth taking further, and I would be happy to help and advise.
~~~~~~~~~

Details of scientific/technical side of the project will be given elsewhere on this blog - including the text of the key refereed publications and a longer list of other papers and conference papers will be provided. Further aspects of the work will be covered in the blog. However a brief summary of the area of the new idea is relevant here.
Computers were initially seen as calculating engines to carry out highly repetitive mathematical tasks accurately. These tasks are ones which humans find difficult and are about as far away from the types on information processing tasks the human hunter gatherer would have needed. In the 1950's and 60's there was a major stampede to exploit computers and the all the research efforts were to get faster machines with more memory and easier to program onto the market. Because of the rush anyone who paused to carry out relevant "blue sky" research would simply be trampled underfoot.
This story is about a piece of "blue sky" research that started in the mid 1960s which asked the question "Is there an alternative information processing architecture which will handle open-ended real world logic problems which would be more compatible to the ways people think."
This is potentially a very interesting question, relating to a technology which now dominates everyday life in the more advanced countries of the world. It is therefore relevant to ask whether the project failed because it was merely looking for the pot of gold at the end of the rainbow, or whether it failed because it was incompatible with the way in which computer experts and society view the success of the digital computer.
Early Days
As the person who initiated the research and follow through to the end a quick resume of features of my early life affected my view of the world and the way CODIL developed.
My relations with other people have been significantly affected by childhood bullying couple with the fact that for a time we lived over my father's shop, where I learnt that my duty was to serve others and I should otherwise be seen and not heard.
Four years at a boarding school led to me being really enthusiastic about science and I got involved in helping experienced researches in the fields of bat banding, collecting invertebrate animals, and palaeontology - and later did some studies on my own in limestone geomorphology. I became a regular reader of New Scientist from issue one. I did a first degree in Chemistry at University College London and went on to do research in theoretical organic chemistry at Exeter. As a result I would describe myself as a Science generalist - being more interested in how different disciplines fit together than becoming an in-depth specialist in a narrow area.
Complex information in a Changing World
In 1962 I joined the Cooper Technical Bureau - which had just become a veterinary section within the Wellcome foundation. I was employed as an information scientist whose job was to monitor and report on research and development activities in the Australia, South and central Africa, and the United States. While some of the information involved field trials of products topics could be very variable - changing legislation  in the USA, news picked up from a competitor's salesman, the outbreak of pesticide resistance, etc. etc. An important aspect of the wok of the department was good quality reporting of significant developments to the Board. A big problem was filing the documents. Every chemical of interest started with a single screening report that included activity which could lead to a product. Some would "die" quickly but a significant chemical could expand to multiple products dealing with multiple pests in several different parts of the world - with perhaps 5000 documents in a few years. I proposed and implemented some hierarchical rules for controlling such situations and this later proved relevant in may initial thoughts in the design of CODIL.
After three years I decided that computers would make my work easier, and when I could not persuade my employers to let me move in that direction I moved to work in a very commercial  instalation.

Programming the Computer
In 1965 I joined Shell-Mex and BP to become a systems analyst, after a short period learning to program  the Leo computers in a very large data processing department.  On the day I arrived there was a major crisis due to a major reorganisation going wrong - loosing the records of tens of thousands of customers. Probably as a result I took a particular interest in techniques for ensuring that the programs did what the Sale Division expected - looking for weaknesses in the chain between the ultimate users and the computer. Not realising that it was in any way unusual I suggested that one complex system specification could be implemented by a table driven interpreter - including using the tables to print out the program's specification.

Sales People understand Selling
Having become a competent programmer I transferred to the Systems Department to look at the problems of transferring the contracts for circa 250,000 customers and 5,000 products to a new generation of computers. I quickly discovered many other weaknesses in the user-systems analyst-programmer-computer chain for the existing system. I needed to understand as many different contracts as possible and made many formalised notes which I discussed with the sales clerks. They liked my notes - and I realised I could computerise them. Following the success of the table driven interpreter I proposed a list-driven interpreter approach when the lists represented the sales contracts in a sales staff friendly manner, with the lists being held on the relevant data base records - rather than being part of the memory resident program. If the sales staff could input the contracts themselves this would provide a more flexible and more friendly accounts system.
I was totally unaware that I was suggesting anything unusual - and in retrospect if I had came up with the idea 20 years later I would have been able to describe it as an object-oriented expert system whit about 1,000,000 production rules distributed through the data base. The idea was rejected but I understand that a very simplified version, called Variants, was implemented after I left the company and may still be in use.

Looking towards the Future
In the summer of 1967 I joined the Market Division of English Electric Leo Marconi as the "ideas man" in a two man team looking at the future requirements for top ot the range commercial systems. This involved in depth discussions with people as different as central processor designers on the future trends in hardware and a senior manager in British Steel on the payroll problems caused by the complex union agreements. I also learnt to program the System 4 Computer (an IBM 360 look-alike) and discovered how different the instruction sets could be on different makes of computer. At a very early stage I was asked to review proposals for a library software package, and in my report I reconstructed some of the problems I had handled manually when working as an information scientist. I did not initially think anything of the fact that my notes were written in a format compatible with my work on sales contracts. However I soon started asking some penetrating questions about the ease of modifying a computer's instruction set, and the use of associative memory systems.

A Very Different Solution
It was not long before I realised that the ideas which had started with the sales contracts system could be generalised and the list processing algorithm could relatively easily be implemented by adding extra instruction codes to IBM instruction set. Encouraged by my immediate boss I submitted provisional proposals to John Aris saying "The basic approach is to design a system oriented towards human-computer interaction (in the logic sense.) So far much more work needs to be done, both in filling in the holes and extending the the idea further. However the further the idea is extended the simpler it becomes. I feel that this can be explained in that I am trying to emulate human thought by computer." The opening section of the attached report said "The idea is to design an information processing system for an unknown user with some data and access to an unspecified computer."
The basic approach being proposed is described the the 1971 Computer Journal papers and will not be repeated here. In hardware terms what I was suggesting could easily be accommodated with existing hardware systems by altering the instruction set - or introducing new instruction codes alongside a conventional set for upwards compatibility reasons. The really big difference is one of philosophy.
The conventional stored program model starts with the existence of a predefined algorithm which defines the rules by which numbers are manipulated. The kinds of tasks for which the earliest computers were used were ones where a good human interface at the machine instruction was irrelevant. More and more complex programs can be created by predefining additional processing options - but the cost escalate as the complexity of the resulting algorithm increases. If a situation occurs which has not been pre-defined it cannot immediately be done.
The CODIL model starts from a diametrically opposite viewpoint. Bearing in mind that I had worked on very complex manual information processing systems and on one of the most complex commercial computer system my starting point is that the world is very complex, and whatever we do the unexpected will happen. In addition the unusual and unpredicted event often the most important to get right. With this in mind the most useful tool will allow humans and information processor to work closely together in novel and changing situations as well as in the more routine. So the starting assumption is that that we don't know what is going to happen next - so an a priori global model is impossible. The task is to design a system which humans can "drive" when you don't even know the applications in advance,
Many of the trials and tribulations described later in this history can be explained in terms of a computer establishment which is dedicated to the "intelligent design" of precisely defined programs, and which holds the funding purse strings, and manages peer reviews. It seems that people who have accepted the idea that "programming the computer" is the only way forward find it very difficult to imagine an approach in which human and information processor work in a symbiotic way to "evolve" a dynamically changing system.
[Note - if anyone who worked with me reads this the original project name was DORID - Data Oriented Information System.]

Implementing the Pilot Program
Within days of preparing this report I was moved to the Research Division to draw up more detailed proposals, and produced detailed reports titled A Brief Introduction, Data Structure, An Introduction to Scientific Information Retrieval, Problem Solving, Sales Accounting, The effects on Hardware, A Comparison with the Relational Data File, and Terms of Reference for the Pilot Program Project.
Early in 1968 I moved full time to research, with an internal budget  and two programmers, the whole being actively supported by the computer pioneers David Cameron and John Pinkerton. Progress was good, patents were applied for and by the end of 1969 I had done everything I had proposed in the project specification, and more.

New Management and Out
Unfortunately by this time there had been a big computer company merger to form ICL.  The Research Division I was in was closed down, and there were discussions as to whether the CODIL project could be relocated. The new Research Director, Basil de Ferranti, showed significant interest and asked me to prepare a Board level presentation of my work. The presentation was "given" but unfortunately not one of the directors turned up - and only one even bothered to send a substitute. Effective the project ended up being "vetoed" by the Board without even having a proper assessment.
Following discussions with John Pinkerton it was agreed the the work should be published (see The CODIL language and its interpreter ) and as long as no adverse publicity was involved I could move with the research, and access to the patents, to a university. Because of the delays I had not found a suitable place before I was made redundant.
Two days after I left ICL and joined the dole queue I presented the first full paper on CODIL at one of the first ever international man-computer interaction conferences.

A Military Limbo     As I hadn't found a University opening I needed a job, and the sign on the right of the gate said "London Air Traffic Control Centre." And so on the first day, as a life-long pacifist, I entered a large rectangular building at the back of the Air Traffic Control Centre and was shown the War Control Room. I was trapped in another box - with a wife and three children to support I could not afford to walk out - so I just had to grin and bear it. However I soon realised that Linesman, as the £100 million plus project was called, was so flawed it was very unlikely to work, and being an honest scientist I insisted in raising a number of technical difficulties in the human-computer interface. This did not go down with the company management who decided I would not get an annual rise. Despite this a couple of weeks later the software manager requested that I became his "personal assistant" - in practice his "trouble shooter." When I decided to give in my notice a couple of months later they actually tried to bribe me to stay...
     The most frustrating thing was that I could have adequately funded my research on about 0.1% of the money being squandered on this ill-conceived project.


The Choice
     My search for a University opening improved once my Computer Journal papers appeared, but I had been so busy looking for a place to continue with the research that I had thought through what kind of working environment would be best. When I had come up with the initial proposals for CODIL I had significant support from my employer - at least until the effects of the merger cut in. I also hadn't realised how unconventional the approach appeared to most people working in the computer industry.  My childhood bullying experience has left me as a quiet, retiring, back room boy, who was ill-equipped to fight the battles with the establishment, and who needed good management support, and a fertile environment.  A university that merely supplied a salary, computer, and time, would not be enough.
     At the time the choice seemed easy. I had two interviews lined up. One was as Reader in Computer Science at Brunel University - a good hike up in salary, and near enough home to avoid having to move house. The other was as Assistant Lecturer at Cambridge, a drop in salary, and a move. The Reader post interview was first, and when I was offered it I accepted and cancelled the other interview. Such an obvious decision but in retrospect the wrong one.

Into the Frying Pan
     When I arrived at Brunel University I soon discovered the snags. The only computer really suitable for the work was an ICL batch system - so no terminal working - with very limited support software pr skilled technical support. Even worse I found myself "piggy in the middle" between the Manager of the University Computer Unit, who considered that he should have been professor of Computer Science, and the actual professor, who revelled in publically making jokes about the incompetence of the Computer Centre Manager and his staff. My professor was friendly enough, but seemed to have little concept of research while the day to day department management was safer if left in the hands of the departmental secretary (underpaid female of course). The University  had old just been created by upgrading a technical college and few, if any, of my colleagues had any significant research experience - and some had little experience of using computers except to teach them. Overall it was not a good environment for a somewhat timid introvert to carry out blue sky research which challenged the establishment position.
     Despite these problems it did not take long to produce a new and improved version of the interpreter software, basically aimed at the more commercial types of application, and written in COBOL as the most appropriate language available for handling larger files. I started testing on a variety of tasks and soon was running a live application involving a specialist medical data base recording the case histories of heart surgery patients.


But it is not Artificial Intelligence
     Once I had a reasonable version of the CODIL interpreter working I started looking for different applications. A colleague suggested that I should look at the work being done on artificial intelligence. I commented that the field looked difficult he commented that there was a lot of showmanship to disguise little substance and gave me a copy of a Ph.D. thesis from a leading A.I. centre to see what was actually involved. Within a week I had the interpreter doing everything described in the Ph.D. thesis in a much more elegant and user-friendly way. Not long after I succeeded in using it to solve 15 consecutive Tantalizers - the logic puzzles published every week in the News Scientist. Soon the interpreter was driving a CODIL file which asked for details of the task and generated a set of production rules to solve the task. This was tested on perhaps a dozen different published logic tasks published in the A.I. literature.
    So where are the publications describing these significant results? I can imagine you saying. The answer is very simple - peer review. For instance I submitted a pair of  papers to one conference  - one describing how the system worked, and the other with details of timed computer runs reproducing work described in established A.I. papers. The reason for rejection was that my system could never possibly work. Unofficial feedback (in some cases as verbal insults when I attended conferences) suggested that the problem was really that I was not a member of the elite club led by the departments at Edinburgh and Essex Universities, that all serious work in A.I. was done using a computer language called pop2, that I came from a department with a near zero reputation for research, and that no-one with a commercial computing background was bright enough to understand a subject such as A,I, Under these circumstances, if I came up with ideas that challenged the A.I. establishment I must be wrong.
     With rejections like this I became more and more depressed, and decided to aim high. I submitted a paper to a top U.S. journal and needless to say it came flying back. Two reviews were vitriolic in their condemnation of the paper, one reviewer said he did not understand the paper, and the fourth  reviewer was very favourable. I was so upset that I effectively abandoned all work on A.I. It was only some years later, when I was less emotionally involved, that I realised that the editor had added some very kind words suggesting that I persevere with the research because there must be something there to trigger such violet opposition..

Jim Fixed it for me
     Towards the end of the 1970's I was becoming very depressed, and the number of papers submitted started to fall off. It was clear that I could get papers published on various applications (but not Artificial Intelligence) as long as I didn't try an explain that the results were obtained by using unconventional methods. I needed a large database application for demonstration purposes and a project with the local hospital was unsuitable because it used confidential patient data. I decided to set up a family history data base on the basis that much of the data would come from a wide variety of sources, of variable accuracy, and where uncertainty was a frequent factor. The chief problem was that I started to spend too much time collecting data.
     Then there was than a refreshing incident. Jimmy Saville had a TV show called "Jim'll Fix It" in which children wrote in to ask Jim to help them to to do something. An 11 year boy wrote to ask if Jim would get a computer to "do his homework" and our university was ask to set something up. I used CODIL to provide a number of demonstrations that I thought would interest him, which  was not actually used on the programme. However shortly afterwards the University was getting a new service computer and overnight everyone was expected to switch from batch working to online working. I was asked to spearhead the change with the first online class of 125 first year students (50 Computer Science major, the rest Mathematics major) with very little technical support.
     It may seem strange to modern students, but only about a third of the class had any experience of using s computer of any kind (4 owned their own personal computers), and perhaps a third had not even used a typewriter keyboard. There was a real danger that the "know-alls" in the class would intimidate the complete novices if I gave a conventional introduction to computers. I needed an first assessment exercise that all could do - and "Jim fixed it for me" I converted my software to run on the new computer and added some new features to the Fix It package. The coursework - write a two page essay on how suitable you think the package would be to an 11 year old. This worked well and the exercise was repeated in following years - and CODIL was also used to support some tutoring packages. In fact the project was a useful boost to my formally depressed state as it clearly could demonstrated that the approach was robust.


It doesn't BLEND in
     To be written in the next few days.

Small is Beautiful

The success of the Fixit Package gave me a good idea of how the research could be taken forward. The BBC computer had just been introduced for use in schools and at home, and I started thinking about the potential for CODIL in Schools. While this computer was quite powerful as a teaching machine for its time it was horribly restricted compared with the university main frames that supported the existing version and impossibly limited compared with today's personal computers and mobile phones. For instance there was a total of 25K bytes of random access memory to be shared between the screen display, the input output buffers, the application program, and all working data, including recursion stacks.
     Thinking small clarifies the mind wonderfully. You ask "Is it really necessary to do this?" or "can I merge these two operations by getting them to share code" Modern computers are so powerful that it is often possible to write more and more code without having to  stop and think whether the might be another simpler more-elegant way. The more I streamlines the central processor the more powerful the approach became.
     By the end of 1986 I had a demonstration package, MicroCODIL, aimed at schools which was logically very much more powerful than its main frame predecessor - but unable to handle large tasks because of limited memory for working data and files. There was also a comprehensive manual.  The package was sent out to a variety of magazine, including the New Scientist, for review as a school package without emphasising the unusual internal approach - and the resulting reviews were extremely favourable. I drafted a paper to the Computer Journal which was accepted, and in theory I should have been in an excellent position to get research funding or perhaps even commercial interest, but ... ... ...


No Money - Get Out

Unfortunately this period had been extremely disrupted by family matters. In 1984 my daughter Lucy took an overdoes and ended up in a psychiatric hospital with acute depression. Shortly after returning home (but still an outpatient) she became very excitable and ended up doing something which was not only stupid, but quite clearly illegal. She was taken to a police station where a doctor declared that she was not mentally ill. As a result she ending up what was nicknamed The Muppet House - a hell hole for women prisoners who are too mentally disturbed to submit to the prison rules. (Break a rule - loose privileges - applied repeatedly until you have nothing left to take away except a bare cell and solitary confinement.) She was transferred to a hospital days after a court of appeal case ruled on the prisoner in the adjacent cell., but killed herself on an anniversary associated with her imprisonment.
     This had a very big effect on me. Initially I had considerable support from the University - especially the students, but also my professor. There can be little doubt that the events delayed the launch of MicroCODIL at least 18 months.  However the real problem was the appointment of a new professor, who, to put it mildly, was a vicious bully, and who saw me, in my mentally weakened state, as someone who was easy to humiliate. For instance our department had a very poor record for publishing in the very top academic journals and any reasonable head of department would have been delighted when the Computer Journal accepted my paper. His reaction was to tell me the British Computer Society must be rubbish to accept such nonsence from someone as incompetent as you. Never mind that it had been through a very tough peer review process - he knew better.
     Clearly there was no chance of getting a grant for further research if, at every stage, you have a head of department who sticks a knife in your back at every possible opportunity - and I started to go to pieces.
     At about this time the government introduced a scheme to improve research and teaching in universities by providing a very generous early retirement scheme.  As I had no recent research grants the new professor undoubtedly thought that bullying me to leave would allow him to gain favour as a ruthless hewer of dead wood. It seems very likely that I would have had a complete breakdown if I had stayed under his management - so I to was happy to go.
       A few years later I was told that, after complaints triggered by another department, there had been an internal enquiry and at least 20 people were identified as victims of his bullying approach. To avoid a scandal he was given a year to find another job.

Throwing in the Towel
     I urgently needed a break, and having never had a Sabbatical I decided I needed a complete break. It took a little while to arrange but I ended up on a one year contract with the C.S.I.R.O. in Sydney, Australia, to work on the design of an information system to monitor research on climate change so that the government be kept aware of what was happening. The plan was that I should also visit various Australian Universities and talk at relevant conferences. 
     I started by reviewing a fair number of papers on the subject - with a view to seeing how the research material could be presented online to non-scientists - when it was decided that the project should be aborted (obviously someone in Australia in 1990 thought that climate change was not going to be an important issue) and the head of the project gave in his notice.  As a result I switched to another project - which was to look at the human factors end of a proposed data base for Australian Heritage. The pilot area was a small patch of Tasmanian rain forest - and while I found it very interesting the project ran into difficulties after I finished because the rest of the team were far more interested in demonstrating their software writing skills, than in understanding what zoologists and botanists actually wanted to use the system for!
     By the time I returned to the UK the BBC Computer was effectively obsolete, and its immediate successor, the Archimedes, was clearly not going to be a great commercial success. The way forward seemed to be IBM style personal computer but did I really want to go on. The more people became committed to the conventional computer approach, with huge investments in both programs and data bases the bigger the hill I would have to climb to convince them that there was another way. Basically I had burnt myself out and the sensible thing to do was to abandon the research and try and enjoy the rest of my life. All the papers, computer listings, etc, relating to the research ended up in my garage, where they have remained ever since
     Of course I couldn't give up research altogether - but just changed direction to low cost research I could do at home. Prior to going to Australia I had started planning a book on local history, and on my return I wrote The London Gunners Come to Town, an in depth study of life in Hemel Hempstead during the First World War. I thought about setting up as a professional genealogist, but decided that instead I would get onto the web and offer free advice on what is now the Genealogy in Hertfordshire web site, with a suggestion of donations for charity.
     At the same time I produced a computer art package, Psychebrot, as "careware" - shareware software that suggested donations to the UK mental Health charity, Mind.  On returning from Australia I started doing voluntary work for our local Mind Association (now the Herts Mind Network) and within a few years was on the Council of Management (legally a non-executive director) of National Mind, representing the South East of England. Unfortunately I had to give this up due to the stress of another family tragedy. Belinda had been very distressed following her sister's death and she had a serious breakdown but appeared to make a full recovery. Following a minor argument with a neighbour, she was admitted to a psychiatric hospital where she died following mistakes by both the hospital and the police.  I continued representing the people and patients of Hertfordshire as an official observer on a number of high level mental health committees, finally giving up the last of my committee posts in 2010.

The Present Situation
     One of the reasons for my re-interest in CODIL is that we are all getting older and one becomes more aware that one day we will be moved into the final box. In the last few years three computer pioneers who were involved in the early days of CODIL (then called DORIS) have died -  John Pinkerton (1919-1997), David Caminer (1915-2008) and John Aris (1934-2010). A year or so ago my son gently reminded me that I had an office overflowing with books and papers relating to the history of Hertfordshire and the were many boxes of papers relating to my university research, and that when it became necessary to clear the house there would be no option to put much of it into a skip - unless there were clear instructions about how it should be disposed of.  My first reaction was that the CODIL papers provided a very interesting case study of how blue sky research was bypassed in the rush to capitalize on the potential of the stored program computer. I therefore started to write a book on the subject, prior to looking to see if I could find a University that would be interested in holding all or part of the ar drafting a book could well take me quite a long time - as one effect of my old age is a drop in writing speed. Last year I gave a talk on the subject to a local U3A group and as a result I decide the best way forward would be to write a blog. This would be a far quicker way of finding out if there was any interest - and also provide some much needed feedback.
      So towards the end of last year I started exploring the web looking at science oriented blogs, and also chasing up research ideas that could be relevant. Interestingly found that some of the most relevant research was away from the conventional computer field - relating to the development of language, and the evolution of intelligence - including an understanding of the differences between animals and humans. I have already discovered that the central CODIL idea will translate readily onto a neural net model - and it could be that the blog may attract people who are interested in doing further research in this area - as what I can do as an old age pensioner working from a small bedroom office is limited.