Here’s a GUI for the Fortran Package Manager that I just vibe-coded using Claude Opus 5.5. Repo is: GitHub - jacobwilliams/VibeFPMGUI: A vibe-coded GUI for the Fortran Package Manager or something · GitHub
It’s just trivially easy to make whatever we want now. I spent almost no time on this. This one is written in Python/Pyside6 and has some nice features. I may expand it.
Sometimes I wonder with such tools if they should be editor plugins, say in VS Code, Sublime, IntelliJ, Cursor and so forth. The downside is maintaining a plugin for different editors is too much work.
The opposite way, providing a new editor is also not attractive, as it becomes a much bigger task and everyone already has their favorite.
And… this morning i’ve added AI code reviews, using free local models (that you can download from Ollama). This is epic feature creep!!
Now translate from Python to Fortran. Unless you are moving from Fortran to Python, that is. 
Hmmm…the only question is this: do i vibe code a Fortran/Qt binding… or do I have it just convert all of Qt to Fortran?
Now we are talking. Of course you convert a subset of Qt that you need to Fortran. Call the system graphics bindings directly.
Why stop there? Convert OS kernel into Fortran and just boot directly into Fortran bliss!
We are not stopping there. But we do have to start somewhere too.
Most GUI systems are designed with OOP. Given that Fortran has support for OOP, having a native GUI system might be a good idea.
So, I got fortls hooked up to. So now it has language server features (go to definition, mouseover tooltips, etc.) Also have fprettify for autoformatting.
See overview of the whole thing here: VibeFPMGUI — a desktop GUI for the Fortran Package Manager
This was all done within 1 day of vibe-coding. Astounding!
The dependency graph can be dynamic. Here I’m flagging version conflicts (if one dependency specifies one tag and another one specifies a different one)
Excellent! So @certik, when will LFortran compile itself? 
(The following is slightly off topic, sorry)
Apparently you can decompile stuff now (see [this](https://youtu.be/rRQzrQLZRWM?is=dusjs8FaBqjzaT7d))
So now you can do:
So then you can have all things in Fortran, even the closed ones 
This is basically what the Rust bros are already doing…
In the AI era, Fortran may actually be in a sweet spot of performance vs easy for a human to read (which is still important for checking what the AI is doing I think). Easy to write no longer matters, so languages that traded performance for ease of writing by humans are probably doomed.
After we deliver. Until then I don’t want to get distracted.
I do want to maintain multiple frontends, so I am thinking moving from C++ to C eventually, to make LFortran itself compile faster, and the lfortran binary to be smaller/leaner, which is a lot easier to do in C. And make our C frontend compile itself.
At that point if we wanted to move to Fortran, it would be easy. After @jacobwilliams ports Linux and the whole desktop to Fortran, he can easily port LFortran also.
I’ll probably stay in C for a while, since the C compilers are really mature and can be fast, and it will take us a while to get as fast (both compile time and runtime). I really want to stay in a very mature ecosystem like C and make sure it runs everywhere. But at least we should try it in Fortran and see if things get faster and what bugs it discovers and how fast things compile, etc.
