The short answer
Why did the first FORTRAN project invest so much work in the compiler’s output? Its original records connect the human cost of preparing numerical programs with the cost of running them on the IBM 704.
Original cost model
Compare totals on the stated assumptions
Preparation and repeated execution contribute differently to total cost.
| Country | Strategy A: 40 + 6n | Strategy B: 100 + 3n |
|---|---|---|
| 10 runs | 100 units | 130 units |
| 20 runs | 160 units | 160 units |
| 100 runs | 640 units | 400 units |
| Necessary conditions | Correct output and adequate storage. | The same procedure, inputs and comparable cost scale. |
Chronology
A timeline of the turning points
Project development
Backus and colleagues developed the numerical language and translator.
Advance reference manual
The manual described the intended system before initial distribution.
Technical paper
The team explained language features and translator organisation.
Distribution letter
Backus announced readiness and specified initial hardware and tape procedures.
Preparation cost and execution cost were separate problems
The 1957 paper presents FORTRAN as a language plus a translator producing IBM 704 programs. The goal was to reduce the work of specifying numerical procedures while retaining efficient execution. Its opening discusses the large share of scientific computing effort spent planning, writing and debugging programs. Those are the authors’ period estimates, not measurements of every computing installation. Backus’s later history adds that earlier automatic systems had made programmers sceptical about execution efficiency. A shorter source program would not persuade them if its translated program wasted expensive machine time.
A numerical language still had physical input and storage limits
The 1956 manual describes numerical scope, single-precision floating-point work and fixed-point integers, while noting that some tasks involving logical machine words were less well expressed. Programs were supplied through punched cards or tape; specified card columns carried labels, continuation information and statements. The manual distinguishes the source machine that translates from the object machine that runs the result. This distinction is practical: having enough resources to run the compiler does not establish that every program it generates will fit the chosen execution machine.
Sources for this section: [2]
The team postponed decisions until it had useful information
The original paper divides the translator into six sections. Some compile formulas or organise indexing; later stages analyse program flow and assign the generated program to the 704’s three actual index registers. It credits Lois Haibt with section 4 and Sheldon Best with section 5, alongside the other named contributors. Symbolic bookkeeping could describe more indexing quantities than the real machine could hold at once. Deciding where to load or store them therefore affected execution cost. This is a concrete hardware constraint, not a claim that every variable in a numerical program occupied an index register.
Sources for this section: [1]
An original cost exercise makes the tradeoff visible
Compare two invented translation strategies for exactly the same correct numerical procedure. Strategy A takes 40 effort units to prepare and translate the program, then 6 machine-cost units per run. Strategy B takes 100 preparation units, then 3 units per run. For this teaching exercise only, assume the units have already been converted to one comparable cost scale, input sizes stay fixed and both outputs fit available storage. Write each total cost after n runs. Which strategy costs less at 10 runs, at 20 runs and at 100 runs? These numbers are invented; they are not a FORTRAN benchmark, a dollar estimate or historical timings.
Suggested answer: the number of uses changes the decision
The totals are A = 40 + 6n and B = 100 + 3n. At 10 runs the totals are 100 and 130, so A costs less. At 20 runs both cost 160. At 100 runs A costs 640 and B costs 400, so B costs less. The break-even follows from 3n = 60. More preparation can be justified by repeated execution, but these assumptions do not select a strategy for every workload. If the outputs differ in correctness, memory fit or input behaviour, the simple comparison no longer answers the decision. These are deductions from the invented cost model, not observations about the original compiler.
A published example was useful evidence with explicit limits
The 1957 paper reports a job written in 47 FORTRAN statements and translated into about 1,000 instructions. The programmer corrected an error in a source statement and recompiled. The authors themselves warn that a case chosen by a system’s creators is a weak general measure of usefulness. Statement count is also not execution time: a loop can execute its instructions many times. Read the case as an illustrated experience, then ask what workloads, comparison methods and repeated measurements a stronger evaluation would need. It is not proof of one universal speedup.
Sources for this section: [1]
Distribution and correction completed the practical system
The 24 April 1957 release letter specifies an initial system requiring at least 4,096 core words, a drum unit and four tape units, with additional instruction requirements. It asks users to protect master copies, send error reports and provide source, output and data when diagnosing problems. Backus acknowledges undiscovered system errors. The October 1956 manual’s planned availability and the later distribution letter must therefore be kept distinct. The question here is why output efficiency and a usable release mattered. The Allen–Cocke guide separately examines the evidence needed for a compiler transformation to preserve meaning.
Continue the chronology
Related history guides
Allen and Cocke: When Is a Compiler Transformation Legal?
Move from the cost motivation for compilation to the distinct problem of preserving meaning when code changes.
Read the timeline1984Knuth’s Literate Programming: One Source, Two Routes
Compare a later attempt to connect a readable explanation with the construction of executable programs.
Read the timelineBiography context
Explore United States through connected lives
Connected biographies
People and research
1924–2007
John Backus
Computer scientist and programming-language researcherJohn Backus led IBM’s original FORTRAN team and pursued ways to make programming easier to express and reason about. His career connected practical numerical compilation, precise language syntax and later experiments in functional programming.Read biography
1932–2020
Frances Allen
Computer scientist, compiler researcher and technical mentorFrances Allen developed ways to analyse programs so compilers could improve their execution. Her work with John Cocke and research teams at IBM connected mathematical descriptions of programs with working systems and parallel computing.Read biography1925–2002
John Cocke
Computer scientist and computer-architecture researcherJohn Cocke linked compiler design with computer architecture at IBM. His collaborations helped establish program-analysis methods and the IBM 801 design, showing why hardware instructions and the software generating them should be considered together.Read biographyQuick answers
Common questions
- Did FORTRAN merely replace symbols with fixed instruction templates?
- The original paper describes a translator that used information about formulas, indexing and program flow to construct efficient output in context. Library routines were also part of the system.
- Does a smaller source program necessarily run faster?
- No. Source length, preparation effort, generated instruction count and execution time measure different things.
Primary and institutional sources
How this history was checked
Original records and institutional histories support the historical account. Exercises and comparisons are newly written teaching aids; they do not reproduce historical field notes, software benchmarks or archival illustrations. This article was reviewed on 27 October 2026.
- J. W. Backus and twelve coauthors; Computer History Museum Software Preservation GroupThe FORTRAN Automatic Coding System (1957), pp. 188–198, original reprint
- IBM Applied Science Division and Programming Research Department; Computer History Museum scanProgrammer’s Reference Manual: FORTRAN for the IBM 704 EDPM, 15 October 1956
- IBM; Computer History Museum Software Preservation GroupJohn W. Backus to John Greenstadt, 24 April 1957: initial FORTRAN distribution
- John Backus; Computer History Museum Software Preservation GroupThe History of FORTRAN I, II, and III, History of Programming Languages (1981), pp. 25–45