3.4Learning FORTRAN
FORTRAN was initially designed by Backus, John John Backus and a group of research scientists at IBM. (See Figure 3.6.) The team designed its high-level language in 1954, and then they took some 2.5 years to build the FORTRAN “translator,” as the organization described their compiling system that converted FORTRAN routines into machine code.
IBM released FORTRAN I in April of 1957, and the language and compiler quickly became a standard for software development in the U.S. and Europe. Important for its adoption, IBM distributed the original FORTRAN software and materials for free to its customers who owned IBM hardware, eventually attracting the interest of a standards organization that built consensus around the new language and its features.
The term “FORTRAN” looks like an acronym, but the name is actually an abbreviation for the words “formula translation” or sometimes “formula translating system.” True to its original names, the language was created for solving scientific and engineering problems, and its internal structures were designed to process mathematical equations in a straightforward way. The language included standard mathematical functions, conditional statements, looping structures, variable types, arrays, and other features that would become customary in high-level languages. All variables beginning with the letter I, J, K, L, M, or N were automatically declared as “fixed point” (or integer) values. All other variables were typed as “floating point” (or real) numbers. The language also allowed the programmer to insert comments into his or her code, allowing developers to explain what their routines were doing and where their code still needed work. Arrays
When IBM designed FORTRAN, it was deeply concerned with improving programmer productivity. Large software development projects were already developing a reputation for being over time and over budget, and this “crisis” gained major notoriety in the 1960s. Reflecting on the economics of this issue as early as 1954, Backus wrote: “Programming and debugging accounted for as much as three quarters of the cost of operating a computer; and obviously, as computers got cheaper, this situation would get worse.”20 Early results with the new compiler were promising, however. When compared to low-level languages, FORTRAN programmers often reduced the number of statements that they used to write their code by a factor of 20.
Figure 3.6Gathering of the engineering team that contributed to IBM FORTRAN in the 1950s. (From the ‘Pioneer Banquet’ at the National Computer Conference, Houston, Texas, 1982.) From left to right: Richard Goldberg, Robert Nelson, Lois Haibt, Roy Nutt, Irv Ziller, Sheldon Best, Harlan Herrick, John Backus, and Peter Sheridan. (Courtesy of the Computer History Museum)
But what did it mean to “write code” in the early days of FORTRAN?
In the first batch-processing systems, FORTRAN programmers did not use text editors to write their programs, but they wrote out routines by hand and then entered them on a key punch device that produced 80-column punched cards. The contents of one FORTRAN program statement appeared on each card, though longer statements could span multiple cards. To help with the process of preparing the cards, IBM produced standard coding sheets for programmers to fill out that identified the columns, statement numbers, and FORTRAN language elements. If the programmer checked a special box at the top of the card, the card’s contents would be considered a “comment”, i.e., an explanatory description ignored by the compiler but retained to document what the program did.
Any spaces existing in the final program would also be ignored by the FORTRAN compiler. Spaces were known to cause confusion because they were Formula translation (FORTRAN)hard to discern on the coding sheets—both for programmers and key punch (or card punch) operators. Jim Backus later wrote that his team was criticized for designing the compiler so that it ignored spaces, but an allowance of this type was typical in an era where programmers worked in large teams that had different levels of training. Many needed to use hand-written notes (as well as cumbersome mechanical devices) to accomplish their work, and in these contexts, errors crept in.21
A complete FORTRAN program consisted of a deck of punched cards that a technician could feed into a card reader, which was attached to the mainframe computer. Once the program was loaded into memory it could be compiled, and the technician would receive a report if there were any errors. The process of debugging the program then began, which could take some time to complete and might involve many team members. In batch-processing contexts like these (i.e., before interactive terminals with keyboards), it might take days or weeks to fix a relatively simple logic or runtime error in a program. Debugging
My favorite textbook describing this process for new programmers is Marshal H. Wrubel’s A Primer of Programming for Digital Computers (1959).22 This well-written book includes step-by-step instructions for filling out coding sheets, creating punched cards, loading cards into an IBM 650 system, and then testing programs using a variety of methods. There is also a fascinating chapter comparing the early FORTRAN, IT, and FORTRANSIT compilers—all designed to help scientists solve math problems. Marshal Wrubel (1924–1968) was a Juilliard piano prodigy and a University of Chicago astrophysicist who took up computing in the 1950s and eventually ran the Research Computing Center of Indiana University. He is relatively unknown in the history of computing because he died unexpectedly at the age of 42 on a hike in the mountains of Colorado. Sadly, he published this innovative primer but nothing more about programming. However, he made an important contribution to technical writing with this title.
The first official manual to document the FORTRAN compiler arrived in October 1956, when IBM released the Programmer’s Reference Manual.23 This formal guide offered a short introduction to FORTRAN and gave experienced programmers the information they needed to use the compiler on the IBM 704 system. The book carefully documented each new language feature, highlighting the language’s Formula translation (FORTRAN)keywords and grammar, or what programmers called Statement syntaxstatement syntax. The manual also included a short chapter on how to create solutions for two “sample problems.”
Soon after this, a selection of user-friendly primers teaching FORTRAN began to appear. These introduced the language to a broader audience (i.e., not just IBM customers). These books included Grace E. Mitchell’s Mitchell, Grace E.Programmer’s Primer (1957), Daniel McCracken’s A Guide to FORTRAN Programming (1961), and Elliott Organick’s A Primer for Programming with the FORTRAN Language (1961).24 These books demonstrate that the nascent programming movement was spreading beyond research labs and academic contexts into settings where quantitative calculations were part of everyday work.
As primary sources for historians, the first FORTRAN primers provide evidence of how coding was gradually seeping into public consciousness. Students, business people, and engineers were now the audience for these books, rather than IBM customers who were using just one system. The computer books also document literary developments in technical writing, i.e., the use of a less-formal “author voice” in scientific descriptions. Some of the books felt open-ended, engaging a wider audience. The tutorials also benefited from the gradual shift from batch-processing to time-sharing, which allowed for greater access to computers and a more interactive experience.
Grace E. Mitchell’s Programmer’s Primer was among the most influential books of this era for budding technical writers. (See Figure 3.7.) Although Mitchell was uncredited in the text and the book was published as an IBM reference manual, it was just as pioneering as the commercial tutorials published by mainstream publishers.
Mitchell joined IBM’s FORTRAN group in the Spring