Fortran and coding agents

AI
1

Coding agents such as OpenAI Codex and Claude Code continue to improve. I have used Codex and think computer code will increasingly be written by such agents. Some prominent programmers have said this too. An argument against Fortran has been that it is difficult to find Fortran programmers, both to write new code and to maintain it, but the proficiency of LLMs at Fortran weakens this argument. Since an LLM will write a program for you in the language you request, the question becomes what kinds of programs should be written in Fortran.

Wes McKinney, creator of Pandas, wrote an essay From Human Ergonomics to Agent Ergonomics saying that agents are more productive with compiled languages such as Rust and Go. Fortran and C++ have the same strengths.

I have been building a lot of new software in Go. Except that Iā€™ve never actually written a line of Go in my life. What is going on?

Anyone following my LinkedIn or Twitter/X feed has seen that I have been down a coding agent rabbit hole in recent months. This has included:

  • moneyflow, a TUI accounting system (written in Python)

  • roborev, a continuous background code review system (written in Go). roborev has totally transformed my productivity, by the way.

  • VibePulse, a mediocre version of CodexBar (written in Swift)

  • agent-session-viewer, a session history viewer and search tool for your coding agent sessions (written in Python)

I have multiple other in-progress projects Iā€™ve been creating on nights and weekends that I either plan to open source in the future or retain just for me. Iā€™m working harder and having more fun building than I have in years.

Python and Agents

Python remains a remarkably effective language. Itā€™s concise, readable, and has one of the strongest ecosystems of libraries of all time.

But agentic engineering is different:

  • Fast compile-test cycles matter more than code simplicity and readability. Agents compile-and-test one-to-two orders of magnitude more often than their human counterparts, so any extra friction here is punishing.

  • Painless software distribution feels essential. You may create numerous tools to enable your ā€œagentic loopā€ and self-contained, dependency-free binaries accessible in a coding agent context feel like the right modality.

  • Human ergonomics matters less when humans arenā€™t the primary authors.

In this context, Python has weaknesses: its test cycles are relatively slow and distribution has challenges (though uv helps). Dragging around a Python interpreter has started to feel like the Java Virtual Machine from which we tried so desperately to unburden ourselves.

The reasons that Python has gotten so popular (and why I went down the Python rabbit hole back in 2007 and dedicated many years of my life to popularizing Python for data analysis) are that it is productive and pleasant for humans to write and use. As the hours and days pass by, this benefit feels increasingly moot compared with the evident downsides (performance, memory use, distribution, etc.), especially with an agent doing all the coding for you.

Put another way, human ergonomics in programming languages matters much less now. The readability and simplicity benefits of Python help LLMs generate code, too, but viewed through the ā€œannealingā€ lens of the iterative agentic loop, quicker iterations translate to net improved productivity even factoring in the ā€œoverheadā€ of generating code in a more verbose or more syntactically complex language.

Frictionless Development and Shipping

The winners of this shift to agentic engineering are the languages that have solved the build system, runtime performance, packaging, and distribution problems. Increasingly that looks like Go and Rust:

  • Painlessly build static binaries with zero runtime dependencies

  • Predictable dependency management and code sharing

  • Fast, deterministic builds

  • Lean resource footprint, no just-in-time compilation, good runtime performance

4 Likes
2

Iā€™ve played with Claude Opus in Fortran projects recently and itā€™s really impressive

3 Likes
3

I have been using Codex for R projects recently. Itā€™s good at identifying and using R packages that fit your needs, but running the code, I often get, sometimes after waiting minutes, errors such as

Error in vapply(line_meta, function(m) m$lty, integer(1)) :
values must be type ā€˜integerā€™,
but FUN(X[[1]]) result is type ā€˜doubleā€™

which would not happen with a compiled language.

One R package I use is MixGHD: Model Based Clustering, Classification and Discriminant Analysis Using the Mixture of Generalized Hyperbolic Distributions . The package does not need compilation, which means that it is in pure R, without C, C++, or Fortran code. It would be interesting to experiment with translation of R and Python packages to Fortran using coding agents.

Regarding my original question of what kinds of algorithms belong in Fortran, I think multivariate statistical algorithms are especially well-suited to it. For univariate data one can get by with <vector> double of C++, and in my domain of finance C++ is much more popular than Fortran (although Python is now more popular than C++).

2 Likes