"Specifically, he and his 20-person team have a goal to demonstrate that AI is capable of translating some of the tens of millions of lines of Lab code written in Fortran, an older coding language, into C++, a code language that runs better on modern computers. "
I also use LLMs extensively to refactor Fortran and got to say that they’re great: the accuracy they catch patterns in code e.g. where error handling should be put, what design patterns to use, is insanely impressive (for complex tasks: not so much if phd-level)
The pain point is that we are Fortran enthusiasts, but people generally cares little about this stuff and moves toward the least-friction setup - the fact C++ is perceived as less friction than Fortran at math and science is telling….
What we can do is to keep developing good Fortran packages: math but also all the stuff that makes C and C++ more convenient rn (think Boost library, GUIs, GPU interaction, YAML/structured IO, etc). Maybe we should use LLMs for part of that as well!
Final thought I want to post a link to a really interesting article @clattner_llvm posted about why OpenCL has not made it to dominate AI. I found many similarities with where Fortran is at now.
PS happy Easter everyone!
Such conversion efforts are occurring not just at Los Alamos. There is also
GitHub - akashdhruv/CodeScribe: Command line tool for code translation using generative AI from Argonne
GitHub - HPC-Fortran2CPP/Fortran2Cpp: Fortran2Cpp: A new model designed for the Code translation between the Fortran and C++ from Lawrence Livermore.
There’s a lot to unpack here.
“[…] written in Fortran, an older coding language […]”
I’m always puzzled when people bring up age and seem to think the rest of the argument makes itself. By the logic old = no good, we could throw out a lot of great inventions. I can only assume age is brought up, because it is falsely seen as some indicator for being outdated/not updated for decades - a persistent myth we see parroted even by computer science students who never engaged with the language. It continues to baffle me how many are able to ignore the developments since 90 (i.e. the last 35 years) and talk about 77 when criticising Fortran. I sometimes wonder if the “Fortran is old” argument would be as persistent if the implicit none had been dropped in the 90s and the language had been continued with the name Fortran++. The whole argument is particularly strange when you consider that 1) C++ is older than modern Fortran, 2) C (of which C++ is an extension) is older than the 77 standard. We can talk about modern tooling options still being more limited for Fortran (something many here are addressing), but this point usually isn’t reached by those making the “Fortran is old” argument.
“Being dependent on Fortran alone is risky these days”
I have difficulties wrapping my head around this. What is risky? If the argument is about depending too much on just 1-2 languages, surely, the trend of switching everything to Python and C/C++ should be more alarming?
C++, a code language that runs better on modern computers
Did I miss something? 
I don’t know what kind of code they’re reworking, but if I imagine someone announcing this in my field of research, the whole endeavour would feel rather naive and ill-informed. After all, the existing models are written in a way to leverage Fortran’s strengths and using a style/structure suited to Fortran’s paradigms. Simply translating the code will give you some strange-looking C++ code. If it’s old Fortran code, why not use LLMs to translate it to modern Fortran to leverage new developments? I found LLMs fairly useful for that.
the fact C++ is perceived as less friction than Fortran at math and science is telling
Just the thought of writing C++ for maths and science feels like a tedious slog to me, haha.
P.S. Happy Easter! 
I don’t see why this is so surprising; I see this as a downgrade from what would be possible with source to source translators and stepwise refinement as developed in the formal methods community.
Now, if you train the model yourself, perhaps much of the problems can be avoided. I remember a section in the CS classic Structure and Interpretation of Computer Programs (AKA SICP p. 161 in footnote) that most old Fortran programs had a pattern of map, filter and accumulate, which I suspect hasn’t changed that much.
But adding randomness via the LLM to this code conversion process can’t be a good thing.
The link is broken (?)
EDIT: looks like the whole site is down
EDIT2: was because of my VPN, as suggested by @fxm
You may need to disable VPN. Works for me.
This is my first clue that the person that wrote this is clueless and just recycleing what some other supposed expert told him. Maybe they should go to any large Gov’t HPC system that’s not DoE and ask what language is burning the most cycles on their hundreds of thousands of cores.
… and that’s the dangers of persistent myths “parroted even by computer science students who never engaged with the language”, as I described it earlier. At some point, it becomes accepted as fact even by people in the field, which are then cited as experts by others. These things are hard to get out of the system, because they become self-perpetuating. It’s even worse when these myths become fun trivia when socialising in certain circles. The “Lol, Fortran is old” line is sadly one that will earn you confirmation and cheers among others who’ve not engaged with the language. If there’s one thing people feel they know about it is that “it’s old/no one uses it/it’s only for legacy stuff”.
And BTW, C++ is 40 years old now, which is kinda “old” as well…
Yep, older than modern Fortran. And if you consider it just an extension to C, you could argue much of it is from the 70s.
We have to start writing articles about using AI to convert old C/C++ code into modern, easy to read and maintain Fortran.
Maybe I would if I could find any C/C++ code relevant to what I do.
At least in this case, I think “AI” is a term that serves the function that “dynamic programming” did for Richard Bellman
I spent the Fall quarter (of 1950) at RAND. My first task was to find a name for multistage decision processes. An interesting question is, “Where did the name, dynamic programming, come from?” The 1950s were not good years for mathematical research. We had a very interesting gentleman in Washington named Wilson. He was Secretary of Defense, and he actually had a pathological fear and hatred of the word “research”. I’m not using the term lightly; I’m using it precisely. His face would suffuse, he would turn red, and he would get violent if people used the term research in his presence. You can imagine how he felt, then, about the term mathematical. The RAND Corporation was employed by the Air Force, and the Air Force had Wilson as its boss, essentially. Hence, I felt I had to do something to shield Wilson and the Air Force from the fact that I was really doing mathematics inside the RAND Corporation. What title, what name, could I choose? In the first place I was interested in planning, in decision making, in thinking. But planning, is not a good word for various reasons. I decided therefore to use the word “programming”. I wanted to get across the idea that this was dynamic, this was multistage, this was time-varying. I thought, let’s kill two birds with one stone. Let’s take a word that has an absolutely precise meaning, namely dynamic, in the classical physical sense. It also has a very interesting property as an adjective, and that is it’s impossible to use the word dynamic in a pejorative sense. Try thinking of some combination that will possibly give it a pejorative meaning. It’s impossible. Thus, I thought dynamic programming was a good name. It was something not even a Congressman could object to. So I used it as an umbrella for my activities.
— Richard Bellman, Eye of the Hurricane: An Autobiography (1984, page 159)
The article quotes Dan O’Malley. A preprint he co-authored about the work is Enhancing Code Translation in Language Models with Few-Shot Learning via Retrieval-Augmented
Generation.
C and C++ are really not a good choice for numerical methods. I would understand if they said that Julia is better than Fortran…
Probably have to wait until templates and generic routines finally make it into Fortran. Almost all large scale C++ apps I’ve seen are basically one big collection of templates see openFoam and SU2. Im sure there are others. However, if that day comes and AI can convert either of these to Fortran then I’ll finally become an AI believer.
Do you have any specific prompts or rules that you use when refactoring the code? I have a big project that I wrote during my PhD and have been wanting to refactor the code to fix a lot of my questionable practices over the years, but I never seem to find the time.
I think expanding the FPM project setup with templates for different types of libs/apps could help here (see related github issue). The individual .f90 files for specific templates could be expanded from bare bone skeleton scripts to scripts that already include general routines or import relevant fpm packages/fortran libs (for linear algebra, for example). While it may not be particularly clean to include these directly in the FPM project, if the creation of templates is straightforward and well documented, larger Fortran projects could create templates for all involved programmers to use.
We are preaching to the converted here . A recent presentation by Vincent Lafage about the evolution of Fortran and evolving legacy Fortran codes is at https://www.youtube.com/watch?v=iXodpBBvVQY starting at 8:47. The video (in English) has links to two tutorials on Fortran, in French: Avancé and Expert.