Browse Prior Art Database

Institutionalization of FORTRAN: The Successors to FORTRAN -- Why Does FORTRAN Survive?

IP.com Disclosure Number: IPCOM000129440D
Original Publication Date: 1984-Jan-01
Included in the Prior Art Database: 2005-Oct-06
Document File: 3 page(s) / 19K

Publishing Venue

Software Patent Institute

Related People

BRUCE ROSENBLATT: AUTHOR [+2]

Abstract

I'm not here to talk as a pioneer; I was really a settler of FORTRAN. Settlers are responsible for trying to secure the territory laid out by pioneers. There is probably a close relationship between the longevity of FORTRAN and the activities that settlers look for -- in particular, recruitment, colonization, establishing good supply lines, and finally trying to figure out ways of perpetuating themselves.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 34% of the total text.

Page 1 of 3

THIS DOCUMENT IS AN APPROXIMATE REPRESENTATION OF THE ORIGINAL.

Copyright ©; 1984 by the American Federation of Information Processing Societies, Inc. Used with permission.

Institutionalization of FORTRAN: The Successors to FORTRAN -- Why Does FORTRAN Survive?

BRUCE ROSENBLATT

(Image Omitted: Author's Address: B. Rosenblatt, Standard Oil of California, P.O. Box 3069, San Francisco, CA 94119.)

I'm not here to talk as a pioneer; I was really a settler of FORTRAN. Settlers are responsible for trying to secure the territory laid out by pioneers. There is probably a close relationship between the longevity of FORTRAN and the activities that settlers look for -- in particular, recruitment, colonization, establishing good supply lines, and finally trying to figure out ways of perpetuating themselves.

In the case of recruitment, there has been a lot of discussion about the state of the computer industry at the time FORTRAN was introduced. All the programmers thought they were experts. They had to be; the kinds of programs they were trying to put on machines were either too large, too complex, or too tedious to do manually. They were trying to take these programs and put them on a device that was more expensive (at least relatively) than a human being. They had to take advantage of all the particular nuances of the equipment. So they developed a great deal of expertise, at least in their own minds. As has been mentioned, there was much skepticism that anybody could write a general-purpose program that would be able to do an equivalent job in efficiency. As a result, several kinds of activities were undertaken in order to get recruits.

Standard Oil, where I worked then and still do, had a unique way of doing this. Both Mike Roberts (Mike had been a member of the IBM FORTRAN support team and had recently come to Standard Oil) and I were given the same program to solve, he in FORTRAN and I in assembly language. While I didn't feel that I was equal to Mike in programming capability, I felt comfortable with the job. Mike spent a fairly normal week working 8 to ~ each day and went home Friday night with the problem solved. I worked extremely hard -- long overtime and through the weekend -- and luckily by Monday morning had a solution. I thought my solution was better than Mike's, but the handwriting was on the wall for both me and my cohorts. We quickly became FORTRAN advocates.

Once you solve the recruitment problem, the next problem is supply. In the case of FORTRAN, how do you keep the program up to date, how do you maintain it, and how do you support it? Even in those days, IBM put support people in the field. Unfortunately,

those people probably didn't know as much about FORTRAN as those of us working with it on a day-to-day basis. So it became necessary to establish direct contact with the support group. Luckily this wasn't too hard. The user community was fairly small, and the support group was fairly visible. They attended national meeti...