 |
In the eighties, science undergraduates like me took a course in structured programming at the computer science department. My Alma Mater taught Algol 68; needless to say that Algol 68 is perfectly suited for teaching structured programming, a skill that serves a lifetime. However, elsewhere in the science and engineering departments staff would discourage using such language for production work. At the time, the dominant workhorse for serious numerical work was FORTRAN.
FORTRAN is one of the few languages whose target audience are engineers and scientists. It essentially is a tremendous calculator with general purpose stuff bolted on. The reason it looks like a general purpose language, may be because at the time there were far less specialised programming languages around than today. For a long time your choices were limited to FORTRAN, COBOL or maybe something esoteric like ALGOL. Sure, FORTRAN is being revised up to this day but this is debated as new features may break vintage code or may make it approximate existing languages that have already drawn people away from FORTRAN. For many new science or machine learning projects where raw speed is not the decisive criterion, people choose newcomers like Python. I myself use Python nowadays.
Back then the reasons to use FORTRAN, even against your will, were compelling. Being geared towards computation, it could easily be learned on-the-job by science or engineering students. FORTRAN was the fastest high level language, that is, gave you most results for your limited budget. It was ubiquitous and portable, therefore a large amount of well-tested FORTRAN software and libraries existed. On supercomputers, your only option to write portable software was FORTRAN. In short, your productivity and cooperability depended on you embracing this language.
At age 65, FORTRAN still ranks among the fast languages around for numerical applications. There are various reasons for its speed. Because it was popular and important, FORTRAN had solid optimising compilers that produced quality code. For example, in vintage FORTRAN pointers are a superfluity, which enabled a FORTRAN optimiser to do more than for instance a C optimiser.
Since C99 optimisation can be facilitated by "restricted pointers", vowing that no reference is aliased in the local context, something taken for granted by FORTRAN.
I have vintage FORTRAN code on the shelf that I could have translated into C using a quality tool like f2c. However, f2c does not meet my need for multiprecision types, and adheres to outdated C standards - originating from the early 1980's, it can generate K&R style if you fancy that. Instead I cheerfully invested some free time in writing my own translation tool VIF (VIntage Fortran), a gcc front-end that translates most of FORTRAN 66/77 into C99, exploiting gcc extensions to improve efficiency. VIF can for instance compile vintage SLATEC code into its library.
Frankly, I do not code that much FORTRAN these days. However, for my daughter's high school maths graduation project on the life and work of Katherine Johnson, I recently wrote a simple demo for integrating differential equations using Euler's method to simulate LEM landings on the Moon. A verbose, old-style listing (from VIF) of this program can be found here. For the children to experience 'the scheme in action' using a state of the art programming language on hardware from the space race era, the demo ran on VM/CMS on an emulated IBM 370. It is priceless to see the face of a child when this program actually lands a LEM safely on the Moon's surface.
Throughout my career there have constantly been prophecies on the forthcoming demise of FORTRAN. Yet it is still here, and not only because some years ago NASA was looking for a FORTRAN guru to work on vintage software from the Voyager project, or reaching out to coders to optimise FORTRAN code for the Pleiades supercomputer.
Most likely the reason FORTRAN keeps appearing in programming language rankings is its continuing use in heavy number crunching. Who would consider investing resources in rewriting and retesting zillions of lines of mature production code unless there is a good reason to do so? Innovation takes more than replacing that what works well with something new.
Supposedly FORTRAN will be around as long as the immense body of code written in it, remains in use. Only time will tell FORTRAN's future, though I am convinced that it will survive at least me.
