Fortran and the ''Old Guard'' of Programming Languages

“You’re using Fortran? Seriously? Listen, 1982 called, and they want their leg warmers back.”
— Every developer since 2008

Every once in a while, I run across someone who’s working with Fortran, or COBOL, or Ada, or (if I’m lucky) LISP. These are the old guard of programming languages, and with the exception of LISP*, that is not said with a lot of aspiration. For most developers, jobs that list “3+ years of Fortran” are laughed at (at best).

So it begs a few questions:

• Why is anyone still using Fortran? Or COBOL? Or any of these old languages?
• Regardless of these reasons, should these languages still be used?

Is Fortran Dead?

tl;dr: Fortran isn’t dead.

Honestly, in the right context, Fortran remains a very sharp tool. It’s just that the right context has consistently shrunk over the years and now decades. In fact, “the right context” is almost synonymous now with “large, complex mathematical computations, ideally where time to solve isn’t critical.”

Look, let’s be frank: Fortran is good at math. There are some pretty technical reasons why this is the case: it handles arrays differently than languages like C and C++ (also great candidates for performant mathematical computing), it has great support for slicing up arrays, and it's object-oriented. (No, you didn’t misread that. Fortran is indeed object-oriented these days.)

You should also not make the mistake to think that Fortran is slow. It’s not; it’s actually quite performant in dealing with massive data sets. But the problems at which it excels aren’t the sorts of things that back modern web applications. The result? People using Fortran aren’t visible in the way that React and TypeScript and Java developers are.

What About COBOL? and ADA? and...?

While the reasons that these other older languages are still being used are different than Fortran, the net result is the same. In specific niches, these languages serve a purpose. They do something particularly well.

That said, there’s one other sub-category that should be mentioned, related to Ada in particular. Ada was the language dujour of many a military application in the late 1990s and into the early 2000s. Now, it’s cliche, but true: the government in general is not quick to adopt new technology. If it works, and in many cases, Ada worked, why change?

NOTE: It’s worth being clear that this is an intentional generality. As a notable counter-example, NASA’s Earth Science division recently took their entire giant data store for incoming satellite data and began storing it in the cloud. Not just GovCloud either, but the public, commercially available cloud, using step functions and serverless technology. Just because much of the government is change-averse does not mean that this applies everywhere.

Should Fortran (and Others) Be Dead?

This is a tougher question to answer. Realistically… probably not. But there’s a better question to ask: should Fortran (and others) be used everywhere that they are currently used? That’s a much easier question to answer: absolutely not. There are a ton of places where you’ll see these older languages used simply because “they work.” Even that’s misleading, though. “They work” typically means “the problems they cause don’t create enough pain to warrant rewriting, rehiring modern developers, digging into the old code, etc.” (and the list goes on).

So what’s the decision matrix here? How do you know when enough is enough, versus when enough is “just fine, leave us alone, we’re busy doing work here.” In general, you need to really understand your business problem. Frankly, if things really are “just fine”, and you’re having a very low number of incidents that trouble you and your users, then you could safely move on, not an issue, bigger fish to fry.

But what if you really are seeing a lot of issues, and the barrier for change is just so enormously high (or at least it appears that way) that even with all the problems, it’s still not worth it to change? This is a harder discussion. At some point, cheaper alternatives will show up. In fact, software like Matlab –something that any college math student uses daily in their calculus classes – is starting to out-perform Fortran for many applications. That’s a leading indicator that if you really are considering the cost to move off of Fortran as astronomical, you may be out of touch with real solutions.

Here’s the long and short of it: Fortran and its older siblings are not scalable, maintainable options for longevity. While change is hard and expensive, you’re going to pay increased costs to retain (or train) talent to work in these languages. If I were one of a few hundred people in my state that could program great Fortran, and I knew my company had a real dependence on that language, you’d better believe my cost is going to skyrocket. I’m a commodity!

You need to, minimally, have a plan to move toward a modern solution. Build that plan out, cost it, even take some initial steps to execute it. If things go to hell, then you know that the time may not be right. But if things progress smoothly and excitement, energy, and progress build… well, maybe change is a better option than you think.

* Almost any serious programmer recognizes that LISP is cool. It is classic, timeless, and anyone who can correctly and creatively use mapchar is a giant among their peers.