PETZOLD BOOK BLOG

Charles Petzold on writing books, reading books, and exercising the internal UTM


Recent Entries
< PreviousBrowse the ArchivesNext >
Subscribe to the RSS Feed

FORTRAN

March 20, 2007
New York, N.Y.

In 1971 I graduated high school and in the fall moved into a dormitory at Stevens Institute of Technology, a small but well-regarded engineering and science college in Hoboken, N.J. overlooking the Hudson River and Manhattan Island.

Stevens Tech was the very first college to require all freshman to learn computer programming. At that time, computer-related courses at Stevens Tech were under the domain of the Electrical Engineering department. The required two-semester programming course was E11/E12. The language was FORTRAN.

FORTRAN was a natural for engineering and science students. It was specifically designed to persuade the computer to do hard-core math. In her classic text Programming Languages: History and Fundamentals (Prentice-Hall, 1969), Jean Sammet quotes the opening sentence of the first preliminary report for the specification of FORTRAN dated November 10, 1954: "The IBM Mathematical Formula Translating System or briefly, FORTRAN, will comprise a large set of programs to enable the IBM 704 to accept a concise formulation of a problem in terms of a mathematical notation and to produce automatically a high-speed 704 program for the solution of the problem." (p. 143) FORTRAN was the first major (what we now call) high-level language. Jean Sammet also notes: "Although FORTRAN is considered quite commonplace now [1969], it was not readily or easily accepted at that time. Customers raised many objections, foremost among them was that the compiler probably could not turn out object code as good as their best programmers." (p 144) Plus ça change...

The dialect we learned at Stevens Tech was FORTRAN IV, which by that time had intrinsic support of complex numbers. Complex numbers are often vital in engineering and science applications, yet still today few languages support complex numbers with as much ease as FORTRAN did then. Flow control was based on numbers (not necessarily consecutive) inserted at the beginning of statements in combination with GOTO, IF, and DO statements, but with some particularly interesting variants: a GOTO statement let you list a variable number of line destinations that control would branch to based on whether the value of a particular integer was 1, 2, 3, or so forth (not unlike a switch statement). The IF statement had three destinations depending on whether the result of a particular calculation was less than zero, zero, or greater than zero.

FORTRAN's type statements used the keywords INTEGER, REAL, DOUBLE PRECISION, COMPLEX, and LOGICAL (i.e., Boolean). However, FORTRAN also supported implicit typing based on the first letter of the variable name. In particular, variables beginning with the letters I, J, K, L, M, or N were assumed to be integers; variables beginning with other letters were reals. (Sammet, p. 166-7) I could be wrong, but I believe that this is the origin of the custom of using variables named i, j, and k in for loops in C-family languages today. At least it was for me.

At Stevens Tech we programmed in FORTRAN using punched cards. The card-punching room and the DEC PDP-10 were in the basement of the library. You'd punch your cards and hand them to one of the gurus behind the counter who ran the computer, who would quickly riffle through the deck and say something snotty like "Well, I see a few syntax errors in there but let's run it through anyway." You'd come back later to pick up the paper output. A big stack of paper was particularly shameful because it usually indicated some kind of weird error that caused some ungodly loop that had to be manually shut down by one of the gurus. The basement of the library also had some teletype terminals, but their use was restricted to members of the ACM. The terminals were in a special room, and their users often wore demented hypnotized grins as they communicated directly with the computer.

It wasn't just students who punched cards, though. Sometimes you'd see a professor in there doing some kind of research project, usually with a particularly huge deck of cards.

I didn't much like programming in my first encounter with it in my freshman year. I had two more occasions to use the computer at Stevens Tech: I took a PDP-10 assembly language course with a horrifying textbook written and self-published by our professor with the title Meet MACRO-10, and I remember that course being a complete mystery to me. A course in numerical analysis also involved some FORTRAN programming, but only as a variation of the traditional approaches.

When I graduated in 1975 with a degree in mathematics, I got a job at New York Life Insurance Company as an Actuarial Student. New York Life had a big IBM 370-based system that did all the billing and other processing. But the actuaries did their statistical analysis jobs either with calculators (the incredibly beautiful and unbelievably noisy Friden was still in use at the time but was steadily being replaced with small electronic calculators) or a hand-me-down computer, the IBM 1130. The language, of course, was FORTRAN, and I was soon punching up cards and looking at paper output from that machine. The 1130 had 32K (or was it 16K?) of "core" memory, which made large arrays difficult. If you wanted to use large arrays, you'd basically create a file for that specific purpose. I remember being called upon to revamp a FORTRAN program written by another actuarial student a few years earlier. The program was particularly hard to decipher because she had decided to name all her variables after fruits, such as APPLE, PEAR, BANANA, and so forth.

Not all the actuaries were in favor of moving their calculations to computers. I remember one actuary telling me how only if you did compound-interest and present-value calculations by hand (that is, using a calculator) could you really get an intuitive feel for the ways and patterns in which the numbers grew.

I didn't actually begin to enjoy programming until the later years of the 1970s, when the non-IT programmers at New York Life were allowed to use the company's IBM 370 via TSO terminals and a glorious programming language named PL/I. The modern block-structure of PL/I and the interactivity of TSO (despite its notorious slow speed) made the whole programming experience much more pleasurable. At the same time, I was getting into computers at home by designing and building electronic music instruments. By the late 1970s, I was building a Z-80 based machine that controlled a digital electronic music synthesizer and programming it in assembly language.

But FORTRAN was my first programming language, and in many senses, the first programming language. Interestingly, in its early design, the elegance of the FORTRAN language was considered much less important than the efficiency of the compiler:

John Backus, who led the team at IBM who developed FORTRAN, died Saturday at the age of 82.


Recent Entries
< PreviousBrowse the ArchivesNext >
Subscribe to the RSS Feed

(c) Copyright Charles Petzold
www.charlespetzold.com