The State of Fortran

My first language was Fortran. Whilst I've some lingering affection for the language and that I still use it occasionally I also use other languages, Lisp for instance. It's significantly different to Fortran so I reckon my comments below come from having a wider experience than just Fortran alone.

First, there are things about Fortran that I don't like and have never liked the main culprit being the obtuse formatting and I/O (I'd have altered it if I could!). I'm not alone, one of the reasons Kemeny and Kurtz invented BASIC was that with BASIC all you have to do to print is to use a simple 'Print' statement. I also agree that Fortran hasn't fully kept up with the times but that's understandable given its large and significant role in science and engineering (I shouldn't need to explain that). At least it's lost some of its more egregious points—for instance, the infamous 'GOTO' instruction has long been kaput (and so on).

However, criticizing Fortran isn't the thrust of my argument here, which is the ongoing need to use existing Fortran programs without the need to change them. There are many, many thousands of programs—mathematical and scientific subroutines, etc.—that have been developed over the past 70 or so years which have been shown to be debugged and highly reliable by the fact that they have been and are still used repeatedly to good effect in critical industries such as nuclear, space and civil engineering just to mention a few.

Translating and or rewriting these routines into more modern languages risks introducing errors and bugs, and whilst modern programmers would likely find this ascetically pleasing that ought to be their secondary consideration—the primary one of course being the correct operation of the program they're working on. Even if all that coding were translated successfully, we'd likely still have issues with different compilers interpreting the translated code in subtly different ways to the original Fortran ones, [as I mention below, authentication of the translated code and similarly the new compilers to meet necessary standards alone would be a nightmare].

In short, we cannot guarantee the translated routines will do exactly the same thing or behave in exactly the same way as they did under a native Fortran compiler—at least not without one hell of an effort!

As mentioned, the key issue for keeping this huge library of Fortran routines operational is that it is huge—truly vast (nearly 70 years is tied up in developing Fortran code/libraries across a multitude of disparate industries and endeavors). Moreover, much of it was programmed by scientists and engineers who had a different attitude to today's programmers in that their primary work involved working and rearranging atoms which is much harder than just recompiling the source upon discovery of an error.

In short, engineers and scientist were used to designing hardware that worked properly and reliably the first time—bridges falling down and nuclear reactors melting down the moment they are commissioned would have serious consequences that today's programmers will never experience; often, the first they know of a failure mode in their code is when it comes in from the field after it was supposedly deemed to work. Thus, this 'work-first-time' exactness attitude spilled over into early Fortran programs and has been the mainstay for much of the code written in the language since (it's a significant reason why so many of these programs have been so reliable). Remember, John Backus, Fortran's chief instigator, was trained as an engineer.

Ideally, it would be nice to see new intelligent compilers that could accurately compile all of Fortran's variants as well as other languages, Algol, COBOL, Ada, PL/I, etc. including C etc. in one package as that would allow easy reuse of old 'solid' code. Of course, this will never happen for a multitude of reasons, the first of which is that it would take years and years to fully standardize and authenticate any such compiler to full ANSI/ISO standards comparable to past Fortran ones (especially so when multiple languages are involved). Then there's the problem of who would do the programming (I'd reckon most of today's programmers would hate such work—they'd see it as much worse than writing 'hated' hardware drivers not to mention the need for them to maintain standards and endure rigid discipline across the length of the project—and that could be for quite some years.)

That brings us back to where we started. As noobermin said, old software isn't broken as is so often assumed, moreover for reasons stated, I contend that history has demonstrated that it's often much more reliable than much of today's new code.

For these reasons, I reckon Fortran is going to be around for much longer than many of us care to imagine. History has shown it has staying power whether we like it or not.

Just curious, how do you know that? I would have thought many establishments would have moved on by now. That said, I've a few of my personal programs that still run on IV - no need to change them as they still work fine (but then they're not running under the auspices of some institution where updating has relevance).

I suppose a more relevant question would be what is the breakdown type of institution still using 77 - educational, research, government, commercial etc. (I know airline bookings and traffic systems used a lot of 77 until recently). I note from another poster CERN is using 95.

I'd reckon legacy systems would be more likely to be found in govt. and commercial and updated more likely in research. (I'd expect there'd be a large disparity between the different types of institutions.)