Browse Prior Art Database

Institutionalization of FORTRAN: The Emergence of Load-and-Go Systems for FORTRAN

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

Publishing Venue

Software Patent Institute

Related People

CHARLES DAVIDSON: AUTHOR [+2]

Abstract

In the 1960s I found myself, along with a rapidly growing collection of people, faced with a whole different set of problems in dealing with FORTRAN. The concept of a program that would accept an algorithm stated in algebraic terms and translate it into machine-executable instructions had been developed, implemented, and demonstrated. Those of us trying to spread the gospel and prepare the next generation could see that the world would never be the same. But the tools we had available to spread the word were designed for a different world.

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

Page 1 of 4

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 Emergence of Load-and-Go Systems for FORTRAN

CHARLES DAVIDSON

(Image Omitted: Author's Address: C. Davidson, University of Wisconsin, Department of Computer Sciences, Madison, W1 53706.)

In the 1960s I found myself, along with a rapidly growing collection of people, faced with a whole different set of problems in dealing with FORTRAN. The concept of a program that would accept an algorithm stated in algebraic terms and translate it into machine-executable instructions had been developed, implemented, and demonstrated. Those of us trying to spread the gospel and prepare the next generation could see that the world would never be the same. But the tools we had available to spread the word were designed for a different world.

Let me paint for you the environment educators found themselves facing. In the 1950s the user community was still relatively small. Perhaps 100-150 people at IBM knew something about FORTRAN. In the outside world, the Michigan project on the use of computers in engineering education had begun to open things up. The IBM 650 did as well, but the 650 was not a cheap machine -- and not particularly easy to use, either.

The education problem was this: we had a mass instruction job. In 1960 we started the Engineering Computing Laboratory at the University of Wisconsin. It was dedicated to the proposition that only an illiterate engineer of the 1960s would not know how to use a computer -- and not only how, but also when and when not to use a computer. To know those things, he had to have had a lot of firsthand experience. That meant that if we were going to teach a large number of people, we were going to have to run a great many jobs -- very short jobs, small jobs, and learning-type jobs. For such jobs, the big headache is getting them debugged and working right. As soon as you get the right answers once, the hell with production -- you're through with it and you start on the next one. In other words, you do many short compilations and very little execution.

The scale of such an operation was a major problem in itself. The one existing course given by the Numerical Analysis Department enrolled only 40-50 students a semester. To handle our anticipated 700 students, we developed an automated slide-tape lecture series in 1961, which was used for 10 years by 1000 students a year. Along with Dan McCracken, we were responsible for starting a large number of people in computing -- rightly or wrongly.

By the same token, undertaking the mission meant working with very naive programmers. Not only were there a lot of them, but they needed a lot of help. They could not all seek out an expert consultant to help them get their program working. They had to be able to find out on their own where their mistakes were -- and ther...