[hilbert42]

"But this article isn't about fundamental algorithms being correctly-implemented in an endowment of legacy code, it's about defending a siloed language choice, which seems like an antiquated concern to me."

1. The first comment I would make is that the headline premise is wrong or at least deliberately misleading. Let's start with a correction. I would very much doubt that climate models are written in programming languages from 1950s. The Fortran code of the 1950s was not that much like the Fortran code that I learned in the late 1960s, and that late 1960s code bears little resemblance with modern Fortran code of today. Furthermore, the Fortran standard is certainly not dead, it is being continually updated: http://fortranwiki.org/fortran/show/Standards.

2. When I made comment about libraries going back 60 or so years, this would imply that libraries written in Fortran II ca 1956 or so would pose a problem today. I would suggest that it is not so because the process of updating libraries is formal and strict, thus an updated Fortran II subroutine would work perfectly well with today's modern Fortran. This 'upgrade' process is not like converting code from say Pascal to C or whatever, for here we are still within the confines of the Fortran framework and that that conversion process is well understood, straightforward and procedural.

3. This isn’t my idea, nor am I defending something that I learned decades ago and don't want to give up. Frankly, I do little Fortran programming these days so it's essentially irrelevant to me. The point I made and that I make again is that there is a sophisticated scientific computing environment in existence and it is used by thousands of current researchers and scientists around the world. Scientists would not use antiquated software on cutting edge science if it did not work. The fact is modern Fortran is a modern programming language that delivers the goods par excellence—likely much better than any other language, especially so given its long and mature infrastructure. For example, here are the first two reference I came across on the net, there are thousands more just like this:

https://arxiv.org/abs/hep-ph/0612134

https://www.sciencedirect.com/science/article/abs/pii/S00104...

4. Now let's look at the current situation—'modern' software. To begin, you should read this 27-year old Scientific American article titled 'Software's Chronic Crisis' from September 1994:

https://www.researchgate.net/publication/247573088_Software'...

I would contend that this article is just as relevant today as it was 27 years ago if not more so. In summary it says.

• Programmers work more like undisciplined artists than processional engineers (this problem remains unresolved).

• Essentially programming is not true engineering (since the time of the article, computer science has progressed somewhat but on the ground we still have multitude of unresolved problems).

• If programming is to be likened to engineering then it is in a highly unevolved state somewhat akin to the chemical industry ca 1800. Its practical function or operation is a mismatch with the everyday world or we wouldn't have the proliferation of problems that we currently have.

When, these days, one examines the situation with literally hundreds of different computer languages in existence, it is clear that there isn't enough human time and effort to rationalise them all and develop a coherent set of tools, in essence almost everything around us is only half done. We stand in the midst of an unholy Tower of Babel and it's an unmitigated mess (I could spend hours telling you what's wrong but you'll know that already).

The crux of the problem is that programmers spend much time and resources learning one or more computer languages and that it's dead easy to poke fun at mature languages such as Fortran as being old fashioned and out of date. The fact is they either do not adequately understand them or the reasons why they are used, or it is both.

The fact is it is this very maturity of Fortran that makes it so valuable to scientist and engineers. Those who are not conversant with or do not program in Fortran have simply not understood the reasons for its success.

Scientists and engineers have found the most reliable, stable and best fit available and that is to use a modern version of Fortran—simply because its reliable and it works.

This article only shows authors lack of understanding of the problem.

Oh, BTW, let me add that I have no contention with theoretical computer science models. It's just the divide between theoretical computer science and what happens in practice is as wide as it ever was.

[readflaggedcomm]

I guess the downvotes and this reply indicate I was unclear or wrong, but I can't tell how. I guess suggesting that the rest of us can learn from Fortran is disrespectful to it, which means I'm not interested.

[hilbert42]

"I guess the downvotes and this reply indicate I was unclear or wrong, but I can't tell how. I guess suggesting that the rest of us can learn from Fortran is disrespectful to it, which means I'm not interested."

Please don't get upset about this, you're not alone. I try to state my opinions forthrightly to stimulate debate and sometimes that sounds abrasive, especially so when there's a clash of cultures (which is partly so here). Incidentally, I didn't downvote your comment.

It is hard to summarize or adequately paraphrase all the technical and cultural issues involved with programming here because there are so many, to do so would require a book of explanations. Moreover, an adequate and satisfactory explanation of the problematic issues facing modern computing would have to begin with a high-level overview then it would be necessary to drill down and explain the many underpinning parts one by one. For instance, to provide a proper explanation of why programmers tackle or approach their work in a significantly different way than is done in traditional (well proven) engineering and why this has had a noticeable deleterious effect on programming rigor one would also have to launch into a study of modern-day ergonomics of programming—and this, in and of itself, would be a massive undertaking.

Treating the matter bluntly, which I admit I've done here in my summary of the September 1994 Scientific American article [Software's Chronic Crisis], will definitely alienate many present-day programmers but what else can one do to raise attention about such an important matter in such a short space? How do we raise and restate the fact that not only SciAm's staff writer, W. Wayt Gibbs but also that many others have put forward strong evidence to the effect that the way we tackle practical programming tasks isn't truly professional and that it is this lack of professionalism that is a major contributor to modern-day computing problems—and do so without actually offending anyone? I reckon one cannot, and the fact that even raising the issue (as here) alienates is also problematic (in that it acts as an additional contributory factor that must be managed).

For reasons already mentioned, Fortran has effectively managed to bypass many of these problem because of its historical role and the fact that it successfully services a specific niche field, albeit a very large one.

Many programmers of other languages do not appreciate the fact that one of the main reasons why Fortran still has such a strong hold upon scientific and engineering programming is because of its origins. Fortran's very raison d'être arose directly from a very practical need of electrical engineers to overcome the problem of the assembly language bottleneck, its limitations were that it was not only slow and tedious but also error-prone, especially so when the job was a big one.

It is high tribute indeed that John Backus and his team did such a remarkable job in solving the input bottleneck problem with Fortran; the fact that they did so in such an effective and eloquent way is the reason why Fortran is still alive and well today some 65 years after its initial release. (It's worth taking a minute to read this Wiki on Backus: https://en.wikipedia.org/wiki/John_Backus.)

Thus, from the outset, Fortran was seen as a very useful tool, for the first time scientists and engineers now had a practical and comprehensible way of entering science and engineering data into computers in ways that were essentially analogous with those that they had always used to solve practical problems that required mathematical solutions.

The key point was (and still is) that Fortran programs now allowed for computer input that was easy to understand as it offers a representational view of what was already within the mindset of programmers whose principle interests were in science and engineering and NOT specifically programming per se. That is, Fortran was and is still so successful in those fields because its paradigm or modus operandi allows it to align easily with or follow accepted methodologies and practices—and that this usefulness was immediately obvious to its target audience/users.

Programmers of other languages must get their heads around the key fact that Fortran, scientists and engineers were a dovetail fit from the outset (and they still are). Therefore continue to expect to see climate models and most other [especially large] scientific modelling to be written in Fortran for the foreseeable future!

Nowhere in these posts have I said that Fortran is the best programming language or that it ought to be a kind of universal language—nothing is further from the truth. Essentially, I am just making the point that currently it is the best fit for the job and that it has long demonstrated the fact with its well established lineage of some 65 years.

Initially, I too was underwhelmed by Fortran. When I was first confronted with having to study it I thought that whoever dreamt up this goddamn cryptic system could have made it much more logical and intuitive (back then, there was little to compare it with—not even BASIC) not to mention its seemingly arcane basic input and output statements (format, print and all that horrible Hollerith stuff). To my mind, they were so overly complex as to be essentially impractical (and my errors were numerous).

Of course, the real problem turned out to be me—not the language! Like many programmers who have objected to having to change programming languages and or having to dispense with bad habits in exchange for better ones, initially I too riled against certain programming improvements made in later versions of Fortran, so I well understand where the reluctance to accept Fortran comes from. (This I believe is the crux of the problem. As we can see from the story/article, the author, Partee, has aptly demonstrated his ignorance in such matters, unfortunately he is not alone.)

For instance, early versions of Fortran made much use of the GO TO statement. I loved it, as there was seemingly no end to the amount of spaghetti code that I could write without doing hardly any planning. Moreover, in the days of punched cards, GO TO statements also made programs easy to modify on-the-fly (as most of us had many pre-punched cards that we could insert into a card stack for a quick fix). When GO TO was rightfully depreciated to force a more structured programming style I, like many, initially resented the fact. [FYI: http://fortranwiki.org/fortran/show/Modernizing%2BOld%2BFort...]

I believe that much of the reason for why Fortran is not appreciated for what it is and why it has little currency outside the scientific and engineering communities is this commonplace reluctance of many to take time to appreciate facts or things that are seemingly outside their realm of interest or their immediate need to know. Right, it takes both time and effort to appreciate what Fortran is about and few are actually prepared to invest in either let alone both. Dismissing Fortran as obsolete and irrelevant is thus a much easier option.