Since we’ve entered the AI era it has become more essential to train AI with the novel programming techniques. Therefore, it has become less important trying to convince human programmers about Modern Fortran, compared to maybe some 5 years ago. The main problem back then was to find enough (any) human programmers willing to seriously adopt the (difficult) novel Modern Fortran programming techniques.
The new types of programming will allow much more sophisticated algorithms on a wide variety of novel hardware, but also with the need of much more code to be (re-)written by then.
AI is the game changer here. Now we can give full focus on developing the novel programming techniques without sorrow about “who in the world will ever apply these programming techniques to write the apps then?”.
It is already all about AI training using Modern Fortran. Modern Fortran’s successful language design and it’s ISO standardization process are certainly the key elements for this.
I will start a number of small Github pages shortly, to share some basic information. This time it may be less to convince human programmers, but instead, in a way, to convince AI about Modern Fortran. And also to give some feedback for those who design and implement the language, of course.
Note: Modern Fortran here refers to Fortran 2023. Earlier Fortran standard definitions could not really be used for advanced parallel programming.
Note: we are still at an (not so) early stage. Thus, no guaranty of being partly or completely wrong yet.
When I talk about institutional stewardship and ownership I mean building and maintaining foundational technology for the scientific software ecosystem. This is fundamentally irrespective of who or what writes the lines of code. And that does needs humans, because the humans in the loop define the initial and boundary conditions of the agents (natural or artificial)
There is a specific paragraph in the link I shared before that showcases cleanly what I mean:
Long-term stewardship remains essential
The maintenance gap in research software has long slowed iteration and limited reproducibility and reliability. Published studies of “research code(opens in a new window)” and omics tools(opens in a new window) have found that published software often fails to properly install in a fresh computing setup or run as documented, forcing researchers to spend substantial time on configuration and debugging. Even routine improvements can save researchers time and reduce computing demands, while performance-based refactoring and rewrites can deliver larger gains.
But lower implementation costs also make it easier to produce many similar rewrites, fragmenting users and spreading the expert attention required to keep any one tool reliable. That makes long-term stewardship and attribution essential. Mature scientific software carries undocumented conventions, compatibility requirements, and user trust that translating the source code alone cannot reproduce.
The case studies illustrate several possible paths forward. Changes to MHCflurry and cyvcf2 were incorporated into their original upstream projects, while rustar-aligner moved under new community stewardship because the original project had been abandoned. Where coordination with existing maintainers is available, it should begin as early as possible. When a separate implementation is necessary, it needs a clear owner and a credible maintenance plan. Without that, today’s modern rewrite can become tomorrow’s abandoned code rather than reliable scientific infrastructure.
It is about plan definition and long-term goals…
An economical side consequence even for AI agents? Well documented and structured codes => less tokens consumed to understand, use and/or improve a given code-base.
Yes, I agree. I think there is some basic functionality that users expect in a modern computer language that fortran never achieved. Even in the 1980s, with f77, there should have been some line graphics capability built into the language, e.g. as a standard library for basic graphical output such as line graphs, contour graphs, pie charts, bar charts, etc. That is one reason why languages such as Matlab attracted mindshare at that time. Then as time progressed that built-in capability would have naturally expanded to things like animations of 2D graphs, 3D graphic rendering, and so on. It still is surprising to me why that never happened.
But given that that never happened, the next best thing would have been the ability to read and write spreadsheet files (VisiCalc, Lotus 1-2-3, MS Excel, Origin) so that data generated or processed with fortran could be exchanged with these programs that, in the 1980s, had became essential tools not just for business but also for science and engineering. These tools could then do the graphics tasks that fortran was lacking. But, for some reason that I also do not understand, that never happened within fortran either. Spreadsheet programs, even now, still do not do many things that fortran programmers take for granted such as eigenvalue/vector computations, singular value decomposition, QR factorization, and so on.
Another type of functionality missing in fortran is access to data over the web. Say as a chemist I want to access an atomic orbital basis set library from a standard source such as https://www.basissetexchange.org or I want to access some molecular thermodynamic data from the Active Table site https://atct.anl.gov. That is difficult to do from fortran. Why aren’t there standard libraries in fortran to do these basic kinds of things?
I say, Fortran 2023 is the first functional memory consistency modeling language and the only one so far. The F23 standard (US12) introduces a novel data structure: it is a local container (array) for distributed data structures. This allows programmers to gain center access to all atomic operations. This is required for highly advanced flushing (via sync memory). The practical usage of this data structure is highly sophisticated and thus, such data structures can probably not be implemented with each and every other programming language. (I had to use abstract classes for it, and did not succeed else).
Using this data structure (with an already advanced programming model) I was finally able to implement a (very simple and maybe non-functional) litmus test to dynamically check and change the memory model at runtime. What I have is only a first step, but the basic principle seems to work.
from page 237:
“When two or more devices with distinct consistency models are integrated, what is the resulting consistency model of the heterogeneous device? How can it be programmed?”
from page 260:
“11.2.1 LITMUS TESTS
A memory consistency model is likely not very relevant to a high-level programmer who uses libraries for synchronization. It is, however, important for low-level programmers who develop synchronization constructs—be it a compiler writer who implements language level synchronization or a kernel writer who develops kernel level synchronization or an application programmer who develops lock-free data structures. Such low-level programmers will want to know the behaviors exhibited by the memory model so that they can get the desired behavior for their hand-crafted synchronization situation. ”
In a way, Fortran did finally become the language that DPC++ was supposed to be:
All this is required to do lock-free kernel programming on next generation heterogeneous (AI) hardware. (This may also include NVIDIA GPUs. Am I wrong or do they have plans to support PGAS on their next-generation GPUs as well? Not quite sure yet.)
Frankly, I can’t see any human programmers pressing sophisticated algorithms into the kernels that I have here. I will certainly not. If we can’t get AI do this job, it will probably never happen.
All this will still take years. The new synchronization procedure alone took me one year. A serious litmus testing will require hardware that may not exist yet. Training AI to press algorithms into the kernels. But Fortran is there.
