Ummmm … is it really going to be this easy to just vibe out a Fortran/Qt interface?
Yes, it’s always been the right choice to do everything in just one language with no third-party dependencies, AI just makes it obvious and easy.
Yes, at this point why not take this one step further and just rewrite Qt in Fortran? that would fit Fortran’s object-oriented patterns and strong typing much better
Already discussed above:
I wasn’t quite ready to take that on. Baby steps… ![]()
I fail to understand this entirely, the “game changer” with ai assistants is no computer language needed at all ultimately, just human instructions and machine executions (and vice versa!). Fortran is an intermediary that will be entirely superfluous in the near future.
In the meantime though, Fortran can’t even aspire to be a serious language anymore WITHOUT a built-in string type (sorry, CHARACTER type is inadequate), proper enumeration (enum) support and Generic procedures plus Generic user derived types.
That’s been discussed a few times. AI already has the ability to generate the binary directly, and it will only get better. But it also seems AI itself would benefit from higher-level abstractions and tooling, such as a good language and a compiler. Just like it has the ability to multiply numbers directly, but it still prefers to call a tool to do that.
I think we can fix strings and enums now, but let me first focus on the generics, which is probably more important. We now have a prototype of both of the main proposals. Does the traits proposal fix the “Generic procedures plus Generic user derived types” that you wanted?
I think there will still be cases where you want to understand what the program is doing, especially in the area of your expertise. For example, I have written numerous transpilers to and from Fortran. I don’t look at the code of the transpiler and just care that it generates valid and efficient code. If it can be done in machine code rather than Python, fine. I have also written programs for volatility forecasting and other topics in finance. There I want to be able to read the Fortran/Python/R code and see what formulas have been implemented. I have wondered how to generate LaTex from Fortran for this reason.
Cool to play Qt with Fortran.
I am trying to build it under Windows 10 without pixi. I already have Qt & MSVC on my pc.
I started with:
D:\qt-fortran>fpm build
+ mkdir build\dependencies
qt_c_core.f90 done.
qt_c_core_classes.f90 done.
qt_c_gui.f90 done.
qt_c_opengl.f90 done.
qt_matrix.f90 done.
qtf_core.cpp failed.
[ 15%] Compiling...
In file included from .\.\src\shim\qtf_core.cpp:7:
.\.\src\shim\qtf_common.h:4:10: fatal error: QObject: No such file or directory
4 | #include <QObject>
| ^~~~~~~~~
compilation terminated.
<ERROR> Compilation failed for object " src_shim_qtf_core.cpp.o "
<ERROR> stopping due to failed compilation
STOP 1
It can’t find Qt. My Qt is at D:\Qt.
How do I tell fpm where my Qt is? Will the change in D:\qt-fortran\fpm.toml?
Thanks for help.
Cean
I think once generics are in strings will be very easy.
I’ll be sure to check this out!
I’ve not tried to use it without pixi. Maybe try using the --flag command line argument to pass in the qt include directory?
But, just use pixi. it’s incredibly easy. Just download and type pixi run example and it will download/compile/launch the examples and you don’t have to worry about any of that.
How many G is needed to download? Last time I download a project using qt, it closes to 10G. I only have 15G a month. After that I have no internet for one month.
Some ideas on what the intrinsic string type could look like are in GitHub - urbanjost/M_unicode: UTF-8 support (ISO_10646 support is not required) including case, sorting, intrinsic overloads ... · GitHub, which works at least with LLVM flang, ifx, and gfortran and supports direct use of UTF-8 constants. I have not made a public version with regex and optimized string <==> numeric conversion but I have already been moving character-intensive applications to it with success even though no optimization passes have been made yet. It adds an OOP interface, full basic UTF-8 support (directionality and higher level Unicode functions are not supported), overloads for all the intrinsics, support of C-style escape sequences, and a customizable HTML-like syntax that allows for creating romanji-like substitutions and supports ANSI terminal attributes plus a few other things (HTML entities, for example). It would be nice if an intrinsic type existed that allowed for “Fortranic” style array syntax and some of the function names could be better but I find it preferable to perl and python
string processing myself, except for the current lack of regex support.
The included uni program and the example programs for each procedure and the man-page-style documentation provide usage information. The uni program is a bit overloaded but provides examples
of many of the features that go beyond the current Fortran intrinsics.
It’s so nice to hear from you again, FortranFan! I hope you and your loved ones are doing well, especially in this difficult period for us.
This is a really thought-provoking discussion. I haven’t fully made up my mind yet, but I see this AI revolution as a great opportunity for our beloved Fortran.
What I think I’m beginning to understand, in this rapidly evolving landscape, is that the balance between planning/designing and implementation is shifting almost entirely towards the former. I find that exciting in itself; I love this. As a consequence, the criteria we use to choose the language in which to implement an idea may need to change, at least in part, compared to the pre-AI era.
It seems to me that one of the criteria many people now consider when choosing a language for AI-assisted programming is the quality, maturity, and flexibility of its SDK and toolchain, rather than their own familiarity with the language. I don’t think it’s a coincidence that so many people are using Rust for vibe coding: it has a solid, mature, flexible ecosystem and delivers excellent performance.
Seen from this perspective, I think this could be a great opportunity for Fortran. It has certainly proved its ability to survive several generations of IT; it has a mature ecosystem, and it delivers excellent performance, even though we’re all well aware of its shortcomings.
If I could humbly offer my two cents to those working on the next Fortran standard, I would focus on features that make the language more suitable for areas where we still struggle, such as strings and generics, along the lines of the excellent work by Certik and colleagues (Lfortran rocks). I would also consider relaxing some of the backward-compatibility constraints, which may carry a different weight in the AI era. I can imagine a future in which Fortran could become a serious competitor to Rust, for example.
At least for this transitional phase. Looking a little further ahead, it’s not hard to imagine a new language designed from the ground up to work well with AI-assisted programming. In the meantime, however, a new ISO Fortran standard could carve out a niche for itself, especially in a landscape where Rust’s robustness is challenging Python’s flexibility.
These are just dreams and half-formed ideas spoken out loud, a stream of consciousness that probably makes little sense. Apologies if this comes across as a bit of a ramble.
Stefano
I concord 100% with this, I don’t think (at least in the near future) that expecting an LLM to rebuild from the ground up solutions for every engineering problem at each prompt is a viable solution. The acceleration happens precisely where LLM agents can exploit and improve the software infrastructure to carryout the deterministic side of the design endeavor. So compilers, strong and clean SDKs and ecosystems are even more valuable.
But we are missing one huge piece : without an official distribution channel for Fortran libraries, that broad trustworthiness will not arrive.
Rust has cargo, Python has PyPi/conda/uv/pixi …
The fpm registry was supposed to fill that gap, what happened here?
It needs a dedicated person who can lead it and maintain it. I was hoping it could be you. ![]()
The good news is that with AI, a single person can indeed do all that, while previously you really needed a team.
So if there is interest, we can revive it.
I think the community is waiting for it. A functional channel for distributing and installing packages changes the whole perception of the ecosystem. And coming back to the Agents topic, I guess that by this time anyone using Claude, Codex or whichever other agentic tool has seen the thing checking where is your python interpreter, checking for the packages it needs to build whatever one prompted and if not installing it through some of the regular channels. Or using npm for JavaScript if wanting to craft some advanced UIs.
But that needs infrastructure and a small team dedicated to ensuring security, transparency and reliability. I don’t think such a mission should be trusted to a solo contributor who might not showup for which ever reason.
I’ll cite something chatgpt told me about the topic of building such a tool that I agree with:
- Governance matters as much as the code
For a community package registry, trust is a product feature.
I would want the project to establish:
- Clear stewardship: who operates the service, manages releases, and controls infrastructure.
- Transparent policies: naming, namespace disputes, package eligibility, yanking, and security response.
- Multiple maintainers: no single individual should be a permanent single point of failure.
- Sustainable funding: domain names, storage, backups, CI runners, and maintenance need long-term support.
- Community participation: clear paths for contributions from compiler vendors, HPC centers, research institutes, and package maintainers.
An org should be behind this officially
In the past I have advocated for a Fortran Foundation to take over managing these kinds of issues. Unfortunately, thats going to take some one (are you listening Elon) or some organization(s) with very deep pockets to fund it and I just don’t see that happening any time soon.
We are part of NumFOCUS, and might be able to pay for hosting, etc. But it requires a person to step up and lead this effort. I can’t do it myself, as I need to focus on delivering LFortran. If nobody steps up, I might be able to do it maybe in a year or so. By then LFortran should be in high-quality beta and interoperability with fpm will be essential, so we’ll work on making sure things work well.
The FPM Package Playground has some features of a registry. There are now 159 packages precompiled with gfortran 16.2, and more can be added. They can be searched by name, GitHub owner, topic, or keyword and have been classified by the Guide to Available Math Software taxonomy. The packages have short driver programs you can run online, and there is a button to download the driver and package. If for example you look for codes in
Class G2h3b1b: General nonlinear optimization of a smooth function with smooth equality and inequality nonlinear constraints, user provides first derivatives of function and constraints
it suggests the packages conmin, optgra, psqp, and slsqp with drivers for this problem.
I agree that a registry should be an official, funded project maintained by a group. In the meantime I am open to suggestions for the package playground.