I don’t use fancy editors: I typically copy/paste stuff into chatGPT and then refine my questions as it starts understanding what I need to do. For repetitive tasks I keep refining the same chat, but sometimes I have to start a new one because it seems like after some time, the quality of the responses gets worse so you better start afresh
2 Likes
Interesting. I also see the deterioration of the quality of responses as the chat grows. What I found works well (no surprise at all here) is to paste some code I want reworked, then either a) provide some other reference code and ask it to use the same style/logic, or b) be very specific in how it should be reworked, using precise terminology that’s very closely associated with what I’m looking for. This already came in handy and saved me some time translating 77 to 2003+.
Some of the things that I remember discussing in the 1980s about C was that even simple things, like integer division i/j, were not fully defined by the language. In the integer division case, it was defined when both operands were positive, but not with either or both were negative – in those cases the language allowed the compiler to either round up or round down. C also was more primitive than fortran when working with arrays, especially multidimensional arrays, it had the annoying quirk of always converting parts of expressions to double precision, as if precision control was unimportant to the programmer, and it did not respect parentheses within mathematical expression evaluation. I think these things were corrected in the ANSI 1989 revision of the language, but that was well after C had replaced fortran as the dominant mindshare language. Many programmers were willing to tolerate all those glaring defects just to get away from fortran.
The C language was associated with unix because unix was written in C and all of the system interfaces were defined in terms of C. That carried over naturally to the POSIX system interface definitions in the 1990s. Thus when unix became more popular through the 1970s and 1980s, it carried C along with it. Many places ran unix on their vax computers in the 1980s, even though the same codes would run 2x to 4x faster on the same hardware using DEC fortran and C compilers and its VMS operating system. One thing that drove that decision was the relative cost of the two approaches. Namely, a free C compiler was distributed with all unix machines during that time, and the free f2c “compiler” allowed fortran to be compiled (by first converting to C, and then compiling the C). In contrast, most f77 compilers at that time from the vendors cost extra, sometimes a significant cost.
Another important factor was that in the 1960s and 1970s, fortran was the common language used in science, engineering, and numerical analysis courses in schools. My first numerical methods course in 1974 was based on fortran, just to give one example. That basic course included linear algebra, differential equations, numerical integration, optimization, and special function evaluation, and although I had studied some of that in math courses previously, I must admit that I learned a lot of new math in that course too. The professor had worked in the space program in the 1960s, and he had many entertaining stories about numerical math problems and their solutions, almost all of them in fortran.
Another important aspect of the fall of fortran and the rise of C was the ANSi standardization process in the 1980s. We all know how that played out, but it is interesting to consider what might have happened if there had been a steady process of revision every three or four years during that decade, say in 1980, 1984, 1988, and 1992. That kind of steady progress would have signaled something very different to all the fortran programmers, academic professors, and program managers during that decade, a signal that would have significantly affected language choice decisions.
All of this has affected the trajectory of fortran usage, particularly in the decade of the 1980s, but also since then. Lately, I get the feeling that fortran usage is increasing, even if its percentage use is still low. That’s because more people are coding now than in the 1980s, so the denominator is increasing, not just the numerator. I’m unsure how AI is going to affect that usage. It might help people write new fortran code, it might help convert code from other languages to fortran, or it might deliver the final death blow to fortran.
1 Like
Well, g++ 14.2.0 is very modern and it “runs” C++ very well, but Fortran doesn’t run on it at all!
“C++, a code language that runs better on modern computers”. I don’t agree with this statement. The new flang-new compiler on LLVM runs well on modern computers. The following two statements are true: (1) old Fortran-77 code runs badly on modern computers, but can be translated to modern Fortran without problems. Los Alamos did it for many of their legacy code. (2) Young programmers don’t know Fortran.
Note that I’m only speaking for atmospheric science/Earth system science here (and I’m aware of the popularity of C/C++ in general): Based on the ~300 job applications by young scientists I’ve looked at in the recent past (last ~5-8 years), I’ve noticed 1) Fortran literacy among younger people varies somewhat with where they are based in the world, 2) Fortran literacy is significantly higher than C/C++ literacy (unless they have an engineering background).
This is also a relevant article that I read a few days ago.
I have spent 25 years in academia and research, working extensively with people across many disciplines, from natural sciences to education, engineering, environment, and medicine subfields. One striking observation I had over the years was that some (often highly competent) scientists/engineers have extraordinary solutions for problems that do not exist. They would then put significant effort into synthesizing the problem(s) or (wrongly, from my perspective) adopting them from other disciplines. I have been involved in such projects in the past. I am unsure if my observation is relevant to the topic of this post. But this experience has made me highly wary of judging problems’ significance or relevancy based on the proposed solutions’ complexity or novelty.
3 Likes
I know I’m old (but not that old, I guess). So I don’t really know how that played out exactly.
i read somewhere that initially it was supposed to be Fortran 82… then Fortran 85… then Fortran 88… And finally Fortran 90 came to be only after NAG promised to do a reference implementation. (Is that right or just rumors?)
There is an account of this period by Brian Meek The Fortran (not the foresight) saga: the light and the dark.
2 Likes
From my experience, in the quantum chemistry domain many codes are transitioning to C/C++ because they’re in search of the hot potato of the day: couple years ago was GPU support and now it is putting in ML pipelines into the models. The former mostly done through CUDA interfaces at the C level, since CUDA Fortran was a bit dead until not too long ago. Additionally, OpenMP offloading support was terrible until recently. It took a lot of bug reports of Fortran applications to get to where we are today; whereas, C/C++ people were able to just write interfaces to CUDA and HIP with little to no effort.
I am aware OpenACC exists, it is just not very favored in the QC community (or the one I am privy to). The support via pragma then got more complicated because it kinda locked you to the compiler that worked, making your app not portable by definition.
Now the ML thing via TensorFlow and PyTorch a lot of it is done very easily via Python interfaces, which can be a pain to implement from the Fortran side (specially for people that just want to write papers on things).
Fortran right now in 2025 is very well suited for all of these applications, it just needs someone to do the thankless work of setting things up for the applications people. I am not happy that people abandon a working language just because C/C++ is newer, shinier. I’d rather look at an old F77 GOTO ridden, Hollerith constant polluted code over an undocumented, overly abstracted, overly templated C++ code; any day, no questions or hesitations. The more I’ve learned about C++ in my current job made me appreciate Fortran more.
I think by providing FPM based packages that do a lot of these routines we can incentivize the community to stick to Fortran, something simple that they can just “use flang_cuda_interfaces” from an FPM toml script of via a CMakeLists would be amazing. In the QC community, xtb is probably the most maintained, up-to-date, well designed production code that is written in Fortran. The rest have…their legacy 
On a side note about using LLMs for translating old F77 code: It works well within a certain scope, small routines, getting a sense of GOTOs and weird spaghetti is nice. I have done some good refactoring using these tools. However, there’s a moment in the conversation where the LLM just stops being useful and you’re better off restarting. I find it useful to have it generate some unit tests that I include in my testing to be able to provide something to it to do.
5 Likes
If by “running well” you mean “generate efficient binary code”, then all Fortran compilers do “run well on modern computers”! Some of them are probably better than the others, but I’m not aware of a poor compiler around (at least among the ones that are actively maintained).
This is wrong.
What is true is that some codes were written for vector architectures that didn’t have cache memory, and therefore are not fully cache-friendly on current computers. But this has nothing to do with Fortran 77, it has do with what was the most efficient way to write code back then. Simply translating such code to modern Fortran or to C/C++, without reorganizing it to better use the caches, can’t make them run faster.
Could you elaborate? I’m using gfortran 14.2 and it works well on CPUs.
I could agree if “modern computers” was referring specifically to GPUs and other accelerators. At least that was one of the critiques LANL had in that other report (An evaluation of risks associated with relying on Fortran for mission critical codes for the next 15 years).
I agree with @PierU, this is an over-generalization; the flip-side being that I partially agree with this. Some codes indeed don’t map well to modern architectures, but I think this is true for many C and C++ codes too. One problem with F77 codes is the heavy use of common blocks and static variables (i.e. save), which can be a blocker for multithreading. In the past I’ve met two domain scientists/engineers (one from TUM, one from RWTH) who told me their university engineering departments had large existing codes (finite elements, tribology) which became obsolete as a result of being limited to single-threaded execution only. The younger PhD students did not have the knowledge needed to refactor these programs. Also SciPy had this problem with some of the included ODE solvers. Their solution was to rewrite them in Cython/C, also for other reasons (toolchain availability).
This really varies between organizations. In general I would agree that Fortran was kicked out of CS departments already decades ago. Engineering departments have replaced Fortran with Python/MATLAB/Julia and this process also started decades ago. Many students learn Fortran when confronted with existing applications.
Concerning the translation of Fortran to C++ using LLMs. It is interesting that DARPA is also funding a program to translate C to Rust:
There have also been calls from the US Department of Commerce to drop C++ in new applications in favor of memory-safe languages like Rust and Go. I’m not sure how relevant these calls are to the applications at LANL, which are probably ran behind an air gap anyway.
One problem with legacy Fortran-77 code is that most codes use “hidden extensions” without even knowing that these extensions are used. For example, a code developed over a three decade period was storing addresses into integer variables. At this time, this was OK, as no c-pointers exist in Fortran-77. Today, this prevent the code running on 64-bit architectures. c-pointers have been introduced in Fortran-2003, solving this issue. Another issue with legacy Fortran-77 code is the extensive use of common blocks. This prevents fixed dimensions to be easily increased as problem complexity increases.
1 Like
We are asked to write code that could be used until 2060 and that is easily embedded into python classes. Many languages and compilers will pass away before that (g77, f95, Absoft, Intel?) and it is difficult to predict which one will survive. We can expect the LLVM suite to survive and flang is part of this suite (together with clang and swift).
A small suggestion for Fortran advocacy: could write a small example about a numerical computation, coded in C/C++ and Fortran. Such example should show the advantages of Fortran relative to C/C++. Then we could circulate the example on Twitter/X, BluSky etc
I would do it but unfortunately I don’t know C
A program using multidimensional arrays will be easier to write in Fortran than in bare C++, but a C++ programmer may use libraries such as Eigen or Armadillo. John Burkardt has coded hundreds of the same algorithms in Fortran 90, C++, and C. One could study for which of the algorithms the Fortran code is shorter and easier to understand, and for which algorithms C++ is better. To fairly compare Fortran and C++ one needs to quite proficient in both, so I nominate @ivanpribec
2 Likes
As a simple but not trivial program using multidimensional arrays, please see this example
I created the program above for a post on this forum a while ago (you can find the link to github repo in the post)
I might have another example that uses 4-dimensional arrays, if I can dig it out
1 Like
I think pointers (in the C sense) should be used very moderately. The modern C++ mantra is “no raw pointers”. If a Fortran 77 code was using the default integer to store addresses, it was pragmatism (or short-sightedness) of the original developers. No doubt there may have been concerns like performance (i.e. long ints on a 32-bit architecture), lack of dynamic memory allocation, and so forth.
The size of int was also a problem in C codes, as I’ve written here: Integer 4 or integer 8? - #23 by ivanpribec
Common blocks are indeed a problem. In a code from an aerospace agency, all the big arrays were part of common blocks and they encountered ELF format restrictions (addressing difficulties). This was one of those codes where compilation was part of the application, i.e. the program is recompiled with fixed array sizes (I think NEK5000 does this too). I’ve always seen this as an anti-pattern, but I read it was done like this for performance reasons. On the other-hand explicitly unrolling small-dimensions can be helpful. I believe there are tricks to achieve this in C++. Recently also !$omp unroll was introduced.
In principle common blocks can be refactored automatically by a restructuring tool (see discussion in Making legacy Fortran code type safe through automated program transformation | The Journal of Supercomputing) however it is hard to find the (financial) incentives to grow such tools beyond academic showcases.
Libraries like Eigen and Armadillo can be quite nice and also achieve performance through the use of template meta-programming techniques (one way to imagine this is there is that C++ compilers have an embedded interpreter for a sub-dialect of C++ that is evaluated at compile time). My opinion is, at the end of the day, they still fall short of a full-blown array type like Fortran has. Certainly, C++ performance programmers can achieve very nice things with templates and constexpr, but I wouldn’t recommend this coding style to domain scientists.
This has been said many times before, but an advantage of C++ are the generic containers including std::map (an associative array), std::unordered_map (a hash table) and the associated algorithms. Also the container adaptors like std::stack and std::queue are useful in certain types of problems. I’m afraid that nothing we can build in Fortran (currently) can be as practical or as extensible. Maybe the Fortran generics can fill this gap, but I strongly doubt the committee would be willing to provide any standard algorithms and containers building on the generic feature, due to lack of man-power.
Anyways, if the LANL machine learning approach for Fortran to C++ translation is successful, I see no reason why you couldn’t take the same neural network and retarget it to produce refactored Fortran code. I would recommend writing a good set of tests first.
1 Like
In fact, pointer arithmetic should be used very moderately. I would say, not at all. C-pointers are very useful in modern Fortran to point to external structures. For example, our code uses associative tables, heterogeneous lists, specific file formats and lifo stacks defined in the ANSI-C kernel of the code. These objects can be accessed (in/out) from Fortran, C, C++, python and Java. Other bindings can be developed in future. This way of programming is very powerful because you can deeply control the information exchanged between systems. Pinning is possible in most languages, making this approach effective. I would never use a language missing C-pointers.
1 Like
There is a paper you might be interested: Formula translation in Blitz++, NumPy and modern Fortran: A case study of the language choice tradeoffs. Although I believe the purpose of the paper is to demonstrate the performance and conciseness of PyPy, Fortran version is the most performant comparing to PyPy and C++.
5 Likes