In a different vibe to the title…has anyone used AI and LLMs to refactor or rewrite old Fortran into modern one? There’s lots of going from language to language, but I haven’t seen any papers that attempt to modernize old Fortran
I tried it with a small test program (provided by one of the f77 codes). It took more time to fix the mistakes than if I would have done it myself. This is already one year ago. So likely things have improved a lot. I think the biggest issue for me are the small bugs that are difficult to detect. Yes, humans make those too. But if you wrote it yourself, it is easier to debug. That became very clear in my test. I am affraid that we are all becoming reviewers for these AI beasts. Review is the most boring part of the SW development process.
3 Likes
I use LLMs to rewrite some of my own code (some 77, some modern). They do well enough and save me some time, but a) I use them for small modules only, b) I have reference code I provide the LLM with to demonstrate style and paradigms, c) I know the code so it’s easy and quick to fix when mistakes are made. Out of curiosity, I also let it regenerate some functions to see how close it gets and it’s improved in the last 3 years for fortran. Nevertheless, I still only found it useful and felt comfortable using it as describes above. I doubt it would be much of a timesaver for larger software at this point.
1 Like
I guess if you want something done right you have to do it yourself 
14 Likes
Yes. But AI appears to be improving at a much more rapid rate than I am.
A project from last year (convert this code from xx to yy) failed completely. 12 Months later, with more experience, a much better effort on AI’s part.
What we will be able to do this time next year will be scary.
D.
1 Like
Is the computation wallclock significant enough that performance is a factor? Curious about any performance differences if wallclock is large enough to matter.
The xc2f.py script in Pure-Fortran converts some simple C programs to Fortran, for example
#include <stdio.h>
int main(void)
{
int n, d, is_prime;
for (n = 2; n <= 20; n++) {
is_prime = 1;
for (d = 2; d * d <= n; d++) {
if (n % d == 0) {
is_prime = 0;
break;
}
}
if (is_prime) {
printf("%d\n", n);
}
}
return 0;
}
to
! created by xc2f.py from xprimes.c
program main
implicit none
integer :: d, is_prime, n
do n = 2, 20
is_prime = 1
d = 2
do while (((d**2) <= n))
if (mod(n, d) == 0) then
is_prime = 0
exit
end if
d = d + 1
end do
if (is_prime /= 0) then
! added by xc2f.py: approximated printf format: "%d\n"
write(*,*) n
end if
end do
end program main
Nice post but I think you did use AI to write it. As the Woz told a recent group of graduates, you used Actual Intelligence. 
1 Like
Love it: “Converting Legacy C++ Code To Modern Fortran”.
@krystophny I think has lots of experience with precisely that: converting old C and C++ codes to Fortran, such as various image readers (png, jpeg, etc.), font libraries, etc.
At this point we can easily just use pure Fortran for all dependencies, and rewrite them to Fortran if needed. It is true that the last 5% requires domain knowledge, so it’s still worth it to maintain the translated Fortran code on github for others to use via fpm. Being pure Fortran removes lots of hassles: faster compilation, just one compiler needed, easier build system (fpm), etc.
2 Likes
C++ is an obsolete language that in the year 2026 still relies on header files, because it only recently got a module system that in practice doesn’t work.
Not to mention all the other things that this fellow felt a need to make a two-hour video about:
There’s absolutely nothing “modern” about it.
Once Fortran will be where Swift, Go, and Rust are in terms of modern language features, it would be only natural to see numerical C++ codes being ported (back) to Fortran – as funny as it may sound to some people.
4 Likes
@jacobwilliams, nice “ai-free” article. My experience with porting C/C++ code with AI to Fortran is somewhat similar, except that I would put the bar way below 95%. It (claude/grok or codex) usually gets the first draft okayish but with beginner mistakes like short-circuiting logic (that Fortran does not have), mixing subroutine and function calls, inventing c-interop types and integers…
But I agree with you that generating test cases gets considerably faster with LLM. I also use it to generate doxygen style documentation, and I am usually quite happy with the outcome.
1 Like
Pure Fortran sounds nice, but also utopian. In my personal experience, whenever I want to build a cross-platform library, I end up adding a bit of C, be it to call a sleep function, or get a full path from a relative one, etc… The problem often comes from interactions with the file system.
That said, fpm is making the compilation job so much easier that this is not a real issue anymore.
1 Like
@davidpfister, @jacobwilliams and all, if you’re interested in AI-assisted C++ → Fortran translation, you may want to check my Modern Fortran port of Lemire’s fast-float library:
It does well, often faster than C++, but unfortunately never faster than C - impossibility to inline, character(*) vs. pointer math, impossibility to equivalence dummy arguments, etc., are the usual Fortran bottlenecks.
Anyways I generally have an excellent time using AI tools for Fortran coding. But I suspect the standard deviation w.r.t. the model being used is what drives most experiences - AI is still not settled, so I find it’s very useful to always use the best, most up-to-date model and never fall back to “smaller”/“faster” models that often don’t do what they’re asked for!
I also do that for complete libraries. But in small cases such as this, single-file, single-module implementations in Fortran are a win to me - no build hassle, no include/src folders, etc. let you focus on the science rather than on the “code for code’s sake”.
6 Likes
well, I generally agree for simple cases. But once you start to use modules written for broader application (as stdlib or even smaller codes) you inevitably have to apply “include/src folders etc.”.
Also, I think that for beginners, auto-appearance of .mod files for every module (and .o files once they are compiled) may generate some confusion, especially that their names are taken from module names, not from source files, as typically expected.
1 Like
At one time Cray’s native compiler only emitted a .o file by default. It also served as the .mod file generated by other compilers. There was an option to create a separate .mod file. It’s been a long time since I used Cray’s compilers so I don’t know if this is still the case. At first I hated not having a separate .mod file but in retrospect that might have actually been a better option for Fortran. It would have simplified make files and made life easier for other build systems. Does anyone know where the idea of a separate mod file originated? I can only guess that it was seen as something like a C header file at the time. In my hand made make files I always turn on the compiler options to place mod files in their own .modules subdirectory and not in .include.
I find it’s very useful to always use the best, most up-to-date model and never fall back to “smaller”/“faster” models that often don’t do what they’re asked for
Even with a good model, results will vary. In the same directory Codex 5.5 created a CONTAINed function in two main programs to compute correlation(x, y). That itself is a problem – such a procedure belongs in separate reusable model. In one implementation it used error stop when size(x) /= size(y) and in the other, it set the correlation to 0 and returned. That’s bad, because 0 is a plausible value for a correlation and cannot be used to signal an error.
We should figure out to be as fast as C or faster.
5 Likes
I haven’t really done any speed tests. I wouldn’t expect it to be that much faster. To really test it I’d probably need a stand-alone version of the C++ code but I have no real desire to make that (or use my AI tokens to do it 
)
This is another example!
So it looks like AI is becoming popular as a coding agent very rapidly, and it is best at writing and translating to the languages it has the most examples of, and that are the most general-purpose
with the best tooling and largest number of libraries for; and that GPU support is critical for numeric codes. So everything consolidates down to the most popular and flexible language in each major category. Maybe PHP/Javascript for web applications, C++/Rust for computational and system code, SQL for databases, … ?
So Fortran has to improve rapidly to support GPU and more functionality like graphics. Can AI be used to make Fortran best-in-class for parallel code and help developers generate core libraries for graphics and web and database interfaces?
After the initial consolidations do those languages consolidate to one pseudo language or prose which AI converts directly into machine code?
For Star Trek fans it sounds like the Borg are here. “Resistance is futile”. Where is Captain Picard? Or maybe “Highlander” is a better match? “There can be only one.”..
So it looks llike it is time to start designing a universal pseudo code language. Maybe it should be called “One”. I wonder if ChatGPT can write it for me ? Of course, I think it should look a lot like Fortran.
Xenoglossia is just not a catchy name. I think on second thought maybe the language should be called “Tongues”?