IBM 610 workstation computer 3359

Much of the "ease of use" improvement had nothing to do with the language or its implementation, and much to do with the dramatic increase in online storage capacity, especially in smaller systems.

The 1620s I used in the early 1960s had no online storage. If you wanted to compile a FORTRAN program, you cleared memory, booted the FORTRAN compiler pbutt 1 deck, read in the source program, waited for the intermediate deck to be punched, booted the second pbutt deck, read in the intermediate cards that were just punched, waited until the object deck was punched, then combined the object deck with the library deck and booted *that* stack. Not the fastest, most convenient, or least error-prone process possible, but for a small shop there usually wasn't any possibility of affording the cost of disks.

Putting it another way, the cost of hardware was supreme; the cost of warm bodies (and user convenience) was secondary.

With the falling price of online storage even the smallest installations could buy disks. (Consider the PC: the first PC FORTRAN compiler didn't need or use a hard disk but was exclusively floppy-based...but these days even the copyright message-EULA by itself won't fit on a floppy.)

Valid point; compiler design has significantly improved over the years. However, compilers as a clbutt (not just FORTRAN) usually do a good job of handling the hackwork that at buttembler-level coding has to be worked out by the programmer, and knowing how to handle the hackwork well requires a significant investment into learning the bit-level guts of the operating system on which the program will be run. The use of buttembler code in an application also places severe limits on the portability of the program, which for some applications may be an unacceptable restriction.

Some do, some don't. The WATFOR implementation of FORTRAN on IBSYS on the 704x machines was a pre-S360 one-pbutt compiler that didn't use intermediate files; there were even some one-pbutt compilers on the 1620. On OS-360 the G-level FORTRAN compiler was an amazingly good single-pbutt compiler that used no intermediate files, but the H-level FORTRAN required both intermediate files and a lot of memory (at least "a lot" for the late 1960s -- meaning you could not run it on a machine with less than 256 KB of memory).

While FORTRAN (for the scientific users) and COBOL (for the business community) weren't perfect, by the early 1960s the tide was turning away from the programmer-coder dichotomy (programmers designed the logic of a program; coders translated that logic into computer programs) and programs were more and more written by people who were trained in the field for which the program was being written. The result was a decrease in the number of programmers qualified to write complex buttembler code.

Make that "fewer" and I might agree. "Few" I'll dispute.

Excel (or more accurately, spreadsheets in general) is good for some clbuttes of computation, including (within limits) certain iterative analysis applications. Spreadsheet calculations, however, are not performed in native code and suffer the resulting problems of performance.

CAD *programs* (not *machines*) can do calculations -- but they're by definition optimized for graphic applications. You don't use a CAD application to simlulate nuclear reactions.

Here's the heart of the issue. In Ye Olde Days a scientific shop would typically have FORTRAN as the only high-level language available for applications requiring general-purpose calculation (and COBOL for the business applications). You have a wonderful example of the old joke that "if the only tool you have is a hammer, every problem looks like a nail" and FORTRAN was used to perform tasks for which it wasn't particularly well suited. These days we have both a much more powerful FORTRAN language *and* numerous specialized languages and applications that are optimized for specific uses, so there is no longer a need to use FORTRAN to write every application.

See my comments above about force-fitting applications into FORTRAN. At the same time, the pure business applications were for many years typically implemented in 1401 Autocoder (and many business schools had Autocoder clbuttes because of this), and later used COBOL and RPG which were optimized for such environments.

Joe Morris