John Forbes, Reminiscences. Joined Leo in early 1960. Did a few ‘odd jobs’ for Leo ll. In summer was told that I was to lead a small team writing an Intercode Translator for Leo lll. My immediate questions were, “What is Intercode?” “What is a Translator?” With a small team created Intercode translator
Working closely with Master routine (MR) had Translator and its MR interface working in 1961.
Moved to CLEO compiler in 1962 with a larger team.
In 1963 on spent more time accompanying consultants to answer/explain to prospects how Leo software worked.
In 1964 IBM announced 360. Moved to team designing ‘new range’. Abandonment of ‘new range’, after ‘deal’ with RCA for Spectra series. Worked on System 4 and software support until moving to Canada in 1969
Two points raised I think I can provide comments on.
1. Why CLEO rather than COBOL? This will go down in the annals of LEO history as one of the great internal debates. (I was not party to it).In the red corner we had the proponents of CLEO (Clear Language for Expressing Orders) It was a clearer language than COBOL. It sought to combine the facilities of COBOL AND FORTRAN in the requirements it addressed. And perhaps most importantly it was the brainchild of TRT. In the blue corner we had the proponents of COBOL led by DTC. It was an already accepted high level language. This meant that it would be easier for a company that had COBOL programs to convert from another machine to a LEO machine. (Far-sighted in that uniform tape standards, programming languages had not yet emerged as a long-term goal).
Anyway the RED corner won by a KO and I was instructed to produce a CLEO compiler, for which I was given a somewhat larger team than had been the case with INTERCODE.
2. Why did the CLEO compiler produce output that was input for the Intercode translator?
In the initial design stage, the objective was to produce object code ready for handling by the Master Program in the same format as the Intercode Translator; and we had experience of doing this. Inside the team there had been little if any discussion about whether that was the right way to go. Then came the suggestion (from Mike Josephs, I think) that we should go the Intercode route. The argument for going this way was that the CLEO compiler would be ready sooner, both because it would cut down on some of the work that had to be done in earlier passes of the program and because some additional passes would not be required. The argument against was simply that each compile would take longer. I agreed with the Intercode route, on the understanding that we would later be able to amend the compiler to be expanded to incorporate the translator functions. (Of course, this never happened and many members of the team and I were long gone into other roles soon after the Intercode version was working.)
3. High level languages v low level languages and computer road blocks. The pros and cons of this debate have been well versed for many years. What, even now I believe as I swear at my laptop, is an understanding of what is the critical component that slows down the execution of a program. For many years it was the speed of the cpu. In one organisation I became familiar with a critical long running batch program ran every night. The solution was to get faster tape drives. Surprise! the run time of the critical update program did not decrease.
Now I look at my lap top and wonder why a program takes so long to load or a file to be found. The disc drive has (in my case) become the limiting factor. My experience is that very few installations take the time to analyse where their road blocks are. See https://www.dropbox.com/s/qhekzhfa8jh4lwb/John%20Forbes%20memoir.doc?dl=0