Fortran is alive!
We’re often approached by companies offering software developers for hire. If I’m in a friendly mood, I listen to them politely and answer their questions. One of those questions is inevitably: what skills do you require from your software developers? And, just as inevitably, the discussion takes an awkward turn when I tell them that I need Fortran developers. It’s not just that most of these companies do not offer Fortran developers, they simply don’t know what that language is. More than once, I had to spell the name: F-O-R-T-R-A-N.
Sometimes it’s annoying but more often it makes me feel just a bit proud, like I belong to some old secret cult from days of yore, preserving sacred knowledge. But in fact, that cult is not very secret and the knowledge is not so exclusive. In our niche of scientific software development, Fortran is very much alive and kicking. Even though it ranks after place 20 on Tiobe’s list of popular programming languages.
So, here’s for the people that do not belong to this niche (or cult, if you will). A few of the main reasons why we still work with a language that you thought had ceased to be long ago.
1. The inertia of legacy
There is a huge legacy of extremely valuable Fortran code out there. In fact, this reason could also be the 2nd through 5th reason at the same time. If it wasn’t for the legacy, Fortran would have a much harder time to survive. But the fact is that many software systems that we use today for our weather predictions, storm surge predictions, traffic monitoring etc. originated in the eighties. Then, Fortran was the scientific software engineering language of choice (or rather: more or less the only language, there was not really a choice). These systems have been improved for over thirty years and have accumulated the wisdom of generations of scientists and developers. As far as this code is structured well enough and coded neatly, rebuilding them in a different language would be a total waste of resources. So there is a strong argument to keep on building forth on this firm basis (which we do on a daily basis at VORtech).
2. Fortran is efficient (or is it?)
Many Fortran developers will tell you that Fortran is extremely efficient and therefore the best for number crunching. But there is a problem with the logic in this statement. A better way to say it would be: “if you use it for number crunching, it’s efficient”. Or even better: “it allows a straightforward and simple expression of common number crunching tasks and this makes it relatively easy for a compiler to build an efficient executable for such tasks”. The latter expression is obviously less catchy than the previous ones. But the fact is that although making efficient code in Fortran is probably easier, Fortran will not always outperform other languages. And with the modern Fortran dialects, it is even not too hard to make inefficient code.
3. Fortran is easy to learn
Again, a statement that needs some further qualification. The old versions of Fortran (Fortran77) were indeed easy to learn (for some people). But so are many modern languages like Matlab, Python and R. If you’ve never programmed before in your life, you will not find Fortran90 (for example) so easy to learn. Personally, I’ve never been fond of some of the newer language constructs in Fortran95 and later versions. I find other languages in many respects much more intuitive. On the other hand, the newer Fortran versions have done away with much of the mess that was caused by some unfortunate choices in the older versions, like its (lack of) memory management, the implicit type casting and the ominous GOTOs. Which brings me to another point. A language that is easy to learn also allows many untrained developers to build software. And we probably all know where that leads to. In this respect, saying that Fortran is easy to learn is not necessarily a compliment.
4. Fortran is good at HPC
This is unmistakably true. On all the High Performance Computing platforms that I’ve used (except for one), there was a very good Fortran compiler available (although I should admit that there was always a C-compiler as well, even on that Fortran-less exception). This is probably because so much of the number crunching code base is in Fortran and this is also the type of codes that typically run on a supercomputer. Fortran as a language was quick in adding specific parallel constructs (like FORALL and WHERE in Fortran95). I’m not quite sure how popular these are today, as we now mostly use OpenMP annotations to do similar things. But the fact is that the Fortran language has learnt to deal with parallelism early on. And, in addition to argument 2, this makes it strong for High Performance Computing.
5. There are good numerical libraries
This is a bit of a recap of the previously mentioned arguments. Fortran has been the language of choice for high performance computing (which is mostly linear algebra) for decades. Hence we have a legacy of very good numerical libraries, which are well-maintained and optimized for the latest hardware. But once again, this argument will only hold if you are familiar with Fortran. Some other languages have numerical mathematics libraries that are just as good, even if not always as extensive as those for Fortran. Even more: there is a pretty good chance that you will be able to call those brilliant Fortran libraries also from other languages.
Summarising, there is certainly no reason to switch to another language if you are building upon a well-maintained Fortran package. And for particular new projects, Fortran is just as valid a choice as any other language. Old does not necessarily mean obsolete, even in scientific computing.