1. Money
You can opt-out at any time. Please refer to our privacy policy for contact information.

Part Three: FORTRAN The Early “Turning Point”

John Backus organizes the FORTRAN programmers.

By Steve Lohr

FORTRAN

Go To - By Steve Lohr

Reprinted with Permission by Basic Books, A Member of the Perseus Books Group -- Copyright © 2002
John Backus organized the work in a cellular structure. Each of the groups of one, two or three people was an autonomous unit, free to use whatever techniques it deemed best for its assigned job. Yet each group also had to agree on programming specifications with its neighboring sections, so that the software code would work together smoothly. The section groups had separate tasks, but cooperation and collaboration were the norm. Lois Haibt did the “flow” analysis – essentially, predicting where the high-traffic areas of compiler would be, using a mathematical technique called Monte Carlo simulations. “It was the kind of atmosphere where if you couldn’t see what was wrong with your program, you would just turn to the next person,” she recalled. “No one was worried about seeming stupid or possessive of his or her code. We were all just learning together.”

Ziller and Nelson had one of most difficult assignments: analyzing and optimizing the so-called inner loops of the compiler. Fine-tuning the inner loops – essential repeated operations – would be key to making the compiler efficient. Ziller and Nelson would have to automate, in software, the work that human programmers regarded as the height of their craft: squeezing instructions out of those loops.

Theirs was the procedural artistry of programming. They studied the inner loops to find the most efficient method of execution – that is, using the least machine time. They then had to devise the programming statement that would invoke that efficient step – the particular – when the compiler was presented with similar problems – the general case. “It was a repetitive process we developed, a constant iteration of improvements,” Ziller explained. “We were constantly trying to save one ‘load’ or ‘store’ instruction, and juggling the order of execution so that step by step we removed more and more calculations.”

Because machine time was a scarce resource, FORTRAN was debugged mainly at night. In the FORTRAN compiler, the Backus team was working on path-breaking software technology. But they used the traditional programming medium of paper tablets and punched cards, which would die only later, starting in the 1960s – thanks to hardware improvements in memory and storage technology – permitting a programmer to code on a keyboard terminal connected to the computer, and still later, directly on a personal computer. The FORTRAN programmers first wrote their code out on sheets of lined or grid-patterned paper. The programs were then keypunched onto punched cards, and the FORTRAN team did their own keypunching. Next, the cards were placed into a card-reading machine, which deciphered the digital perforations on each card. The card reader then fed the data and programming instructions into the computer, and the program ran. (FORTRAN was actually distributed to customers in late 1957 on magnetic tapes, according to David Sayre, since duplicating the big deck of cards accurately proved very difficult.) For nearly a year, the team rented rooms at the Langdon Hotel, which passed from the New York scene long ago, sleeping a little during the day and staying up all night to get time on the 704 computer in the headquarters annex nearby. At dawn each day, they retreated and placed the most resistant bugs into a folder for special attention and further work. The file was jokingly labeled “Necropolis” – a place of horror and death.

The Fortran project was managed with a light corporate touch. Still, the group did have to conform to certain IBM rules. In administering these Backus, it seems, was all but subversive. At the time, IBM conducted yearly employee reviews called the “Performance Improvement Program,” or PIP, for short. The PIP, like most such programs today, followed a rigid formula, with numbers and rankings. Backus decided the PIP system was ill-suited for measuring the performance of his programmers, so his approach was to mostly ignore it. One afternoon, for example, he called Lois Haibt over for a chat. He talked about her work, said she had been doing an excellent job, and then pushed a small piece of paper across the desk saying, “This is your new salary” – a pleasing raise, as Haibt recalled. As she got up to leave, Backus mentioned in passing, “In case anyone should ask, This was your PIP.”

Related Video
Weiden & Kennedy's John Rowan
Babycenter's Jasmine Kim on the challenge of technology
  1. About.com
  2. Money
  3. Inventors

©2014 About.com. All rights reserved.