[ Jocelyn Ireson-Paine's Home Page | Publications | Dobbs Code Talk Index | Dobbs Blog Version ]

What We Did Fifty Years Ago

I've been reading about the programming language research of the 1950s and 1960s. There are fragments of information in Wikipedia and sundry course notes and so on, but I prefer primary sources. So it pleased me to find a paper by John Backus, who led the team that designed and implemented the first Fortran compiler, for the IBM 704. The paper is The History of Fortran I, II, and III; and I also found A memorial given at the 2007  Conference on Programming Language  Design and Implementation by Alex Aiken of Stanford.

From Aiken's memorial to Backus, I see some things have changed. The IBM 704 compiler had only 25,000 machine instructions: and if I estimate its size by assuming three instructions per statement in some appropriate high-level language, that's fewer than 10,000 statements.

But some things haven't changed. Backus predicted that the compiler  would be completed in six months; it actually took two years.

Admittedly, he did face hard problems. One was register allocation, for which he suggested a two-stage solution. Firstly, compile Fortran to machine code for an IBM 704 with an infinite number of registers. Secondly, transform this to code for the registers actually available. I like that.

I was struck by the sections in The History of Fortran I, II, and III that revealed programmers' attitudes to "automatic programming". Which is what coding in a higher-level notation was called in 1954. How this notation helped you would depend on the automatic programming system. Some were assemblers; some were what Backus calls "interpretive systems" that enabled the programmer to code for a virtual machine having the floating-point and indexing instructions that the real computer lacked, as well as easier input-output. Perhaps — I'm guessing — some were macro processors that did the same. And some were "subroutine fixers" that made it easier to load subroutines from a library and pass them their parameters. Like the EDSAC assembler that I wrote about in Early Calls.

To quote:

Experience with slow "automatic programming" systems, plus their own experience with the problems of organizing loops and address modification, had convinced programmers that efficient programming was something that could not be automated. Another reason that "automatic programming" was not taken seriously by the computing community was due to the energetic public relations efforts of some visionaries spreading the word that their "automatic programming" systems had almost human abilities to understand the language and the needs of the user, whereas closer inspection of those systems would often reveal a complex, exception-ridden performer of clerical tasks that was both difficult to use and inefficient. Whatever the reasons, it is difficult to convey to a reader in the late 1970s the strength of the skepticism about "automatic programming" in general and about its ability to produce efficient programs in particular, as it existed in 1954.

Of course, nobody will look back from 2060 and describe any program of today as a complex, exception-ridden performer of clerical tasks that is both difficult to use and inefficient.