The very name FORTRAN was testimony to the groups obsession with the translator, or compiler an abbreviation for FORmula TRANslating system, which was later trimmed to FORmula TRANslator, as if to suggest something more substantial, not some amorphous system. Backus came up with the name in 1954, to no great enthusiasm from his colleagues. F-O-O-O-RT-R-R-A-A-N, said Herrick, slowly mouthing the syllables as if distasteful for an IBM-sponsored documentary film in 1982. It sounds like something spelled backwards. Yet FORTRAN accurately described the project, and nobody could come up with a better idea, so the name stuck. So, of course, did the language, in use even today on machines ranging from supercomputers to PCs something never imagined by Backus and the rest of the FORTRAN team. The initial goal for FORTRAN was to make programming easier on one machine the successor to the 701 Defense Calculator, the IBM 704.
On 10 November 1954, the FORTRAN group produced a paper that described the FORTRAN language and its goals, Preliminary Report: Specifications for the IBM Mathematical FORmula TRANslating System. Irving Ziller had held onto a copy of the original document, which he retrieved from a cardboard box in his basement. The 29-page report present-ed the math-laden vernacular of the language and its traffic-cop rules for handling operations Fortrans DO, IF, GOTO and STOP commands. Despite its dry title, the report was also a shrewd, at times impassioned, marketing document. It was, in the parlance of modern business, a vision statement, detailing Backus plans and hopes for FORTRAN and his optimistic prediction of its impact. The report reads today as a fascinating mixture of foresight and naïveté. It reiterated the economic arguments about the high and increasing costs of hand-coded programming that Backus made to Hurd in 1953, which got the FORTRAN project started. Then, really warming to the subject, one remark-able paragraph began, Since FORTRAN will virtually eliminate coding and debugging, . . . The coding referred to was the machine code that FOR-TRAN compiler would generate automatically, so that was more descriptive than predictive. But eliminate debugging? The blithe prediction strikes the modern reader as quaintly amusing, given that debugging remains the bane of the programmers existence.
In retrospect, the most powerful economic argument in the 1954 preliminary report was its theme of empowerment. FORTRAN, the report predict-ed, would not only increase the efficiency of programming, but also increase the pool of people who could program a goal of software visionaries ever since.
The amount of knowledge, the report declared, necessary to utilize the 704 effectively by means of FORTRAN is far less than the knowledge required to make effective use of the 704 by direct coding. . . . In fact, a great deal of the information that the programmer needs to know about the FORTRAN system is already embodied in his knowledge of mathematics. Thus it will be possible to make the full capabilities of the 704 available to a much wider range of people than would otherwise be possible without expensive and time-consuming training programs.
John Backus Tours With FORTRAN
With their marketing-and-vision document in hand, John Backus, Ziller, and Herrick traveled the country, speaking to customers who had ordered a 704. They went to Washington, Los Angeles, Pittsburgh, Albuquerque, and elsewhere, espousing their vision of FORTRAN and the future of programming. They had hoped to stir up interest in the project and solicit useful suggestions from informed users, but their enthusiasm fell on deaf ears. The FORTRAN report struck the customers as wishful thinking, especially coming on the heels of the false hopes raised by automatic programming, touted by Grace Hopper and others. Knowledgeable computing customers simply did not believe that FORTRAN the language and its compiler could produce machine code that approached the efficiency of hand-coded programs. Recalling those dispiriting trips, Backus observed, We received almost no suggestions or feedback. FORTRAN, then, had little to do with the modern business truisms about the necessity of being customer-driven and getting users involved in product development. FORTRAN was considered too far over the horizon for customers to take seriously.


