Immortal Elder Gods

According to Geoffrey Cain’s book “Steve Jobs in Exile”, the titular entrepreneur told employees at his NeXT startup that were working on their first workstation that their platform would last maybe into the mid-1990s. All computing platforms rely on their app ecosystems to move them forwards, and some half-blessed, half-cursed platforms enable killer apps that help the platform reach the stratosphere. Eventually, the platform collapses under the weight of ensuring backwards compatibility with all of that software; it cannot move forwards because its existing customer base requires that nothing changes.

He correctly identified an industry trend, but this is more due to leaky abstractions and poor design choices than any law of nature (in fact we have laws for evolving software systems, courtesy of Manny Lehman, and most of these laws were available to Steve). With sufficient investment, you can keep adapting your platform to the future, without disrupting your lucrative past.

So while the technologically-advanced Amiga ran out of steam when the custom chipset that leapt it ahead of its competitors in 1985 held it back in 1990, other vendors kept their platforms relevant through reinvention and sheer bloodyminded effort. It was only in November 2011 that Oracle Solaris 11 dropped compatibility for programs designed to run on Sun Microsystem’s Solaris 1 (a.k.a. SunOS 4.1), which was released in 1991 and supported through 2003; Solaris 1 was a BSD UNIX and all subsequent versions were based on AT&T’s System V Release 4. Windows does a great job at compatibility with existing software, even after replatforming the PC version of the OS from MS-DOS to Windows NT. The Macintosh platform goes through bursts of emulating old variants while establishing new ones: PowerPC Macs ran m68k software; Mac OS X (briefly) ran “Classic” software; Intel Macs (briefly) ran PowerPC software; you are probably reading this at the tail end of ARM Macs (briefly) running Intel software.

Through all this churn, uncertainty for customers, and change in direction, some platforms have quietly plugged away, continuing to work just as well in the 2020s as they did in the 1950s. Literally. We are talking about the three living fossils of programming, perfectly adapted to their niches and thriving while other species come and go around them: 1958’s LISP (which we covered in our Functional Programming issue); 1959’s COBOL; and the oldest of them all, 1957’s Fortran.

Yes, Fortran from that era is set in small caps, and we even use a nice font (Garamond) that shows the small-caps variant correctly. Developed as the “IBM Mathematical Formula Translating System”, the goal of Fortran was to produce a high-level language that made it easy to enter mathematical equations, and produce efficient compiled code that would be acceptable to programmers used to hand-carving assembler statements.

And boy, did people enter mathematical equations! If, at any point in the last few decades, you have taken a flight, or driven a car, or filled a car’s fuel tank with petrol/gasoline or diesel, watched or read a weather forecast, taken medicine, bought something that is made of a modern material, or otherwise made use of the latest advances in science and engineering, you are a part of the great Fortran ecosystem (we can drop the small caps now, as the authors had to given the limited typographic capabilities of the IBM 1401 mainframe machine).

Its longevity is due to its adaptability; FORTRAN 66 introduced library functions, for example, while FORTRAN 77 supported block statements and structured programming. Fortran 90 gave programmers access to lower-case letters (and thus set the name with only the capitalised initial F). Later updates add generic programming, object-oriented programming (even COBOL has this now) and concurrent programming. The irony of the statement from Steve Jobs that opened this article is that while his NeXTSTEP platform indeed came and went, people used NeXT computers to maintain Fortran software that predated the platform’s introduction and that survives today, long after its disappearance.

Your humble author knows this because he is part of the story. One of my earlier jobs, if you skip my newspaper delivery and corner shop assistant phase, was managing a lab of NeXT machines in a physics department. Yes, we installed gfortran, and yes, the astrophysics researchers used them (along with much faster PCs running the upstart Linux platform) to perform image analysis on data in the FITS image format. They did while the atmospheric physics folks were not running their fluid dynamics simulations, anyway. A lot of the code still followed the old FORTRAN layout rules, with line identifiers in the first 5 columns (unless the first column was C to indicate a comment).

Fast forward quite a lot of years, and I found myself helping to build a parallel debugger for high-performance computing (HPC) systems; in other words, thousands of Linux computers all connected together and running the same program at the same time. The answer to the question “how do you expect me to debug this system, run the same gdb command on thousands of computers at the same time?” is “yes, exactly that, thank you”. But you get a nice UI to drive gdb, and to graph the thousands of values you get back from every p command.

Of course, the software we were debugging (or helping others to debug) is overwhelmingly written in Fortran. Sure, some people switched to C++, and it is not pure Fortran, with a combination of non-Euclidean shell scripts and Python drivers setting up the core models, and some of the mathematical heavy lifting might be outsourced to CUDA these days, but so much cutting-edge science depends on Fortran that it is best to think of it as the modern, scientific language that always has been; a demonstration of what a computing ecosystem can be when it adapts with the times.

Cover photo by Julia Koblitz on Unsplash.

Back to top