Learning Fortran (2024)
Key topics
As readers dove into a post about learning Fortran in 2024, many were surprised to find it wasn't about the oldest programming languages, with some expecting discussions on Plankalkül or Flow-Matic. Commenters pointed out that Fortran itself is older than Flow-Matic, and the author's approach wasn't even using the oldest version of Fortran. The discussion sparked a lively debate about the evolution of programming languages, with some suggesting alternative versions of Fortran, like Fortran 4, for a more authentic experience, while others shared tips on writing safer code with older versions.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
9m
Peak period
24
0-6h
Avg / period
10.4
Based on 83 loaded comments
Key moments
- 01Story posted
Dec 17, 2025 at 8:25 AM EST
23 days ago
Step 01 - 02First comment
Dec 17, 2025 at 8:34 AM EST
9m after posting
Step 02 - 03Peak activity
24 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 19, 2025 at 5:26 PM EST
20 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Edit: and just three paragraphs in, the author admits they didn't even bother using the oldest version of FORTRAN itself.
So, "oldest" means "rather early".
FLOW-MATIC's claim to fame was beating Fortran at releasing a working implementation (and having syntax that looked like English, but that's not something to be proud of). Plankalkül, however, has not yet been implemented so if we're only counting releases of working software, it isn't a contender.
Waitaminit, is that why we have "sub" in Visual Basic ?
Style wise, many prefer to reserve functions for things that resemble mathematical functions (i.e. only intent(in) and pure). In some sense a little bit similar to how people tend to use lambdas in python.
The programmer must only specify the behavior of the parameters, i.e. if they are input, output or input-output parameters, like in Ada.
The fact that a parameter is the result is just a matter of syntax, not of semantics. Any other output parameters should behave exactly like the result.
Giving the user low-level control of how memory is used can be very useful for writing fast code. The compiler is not omniscient. Providing the choice is not bad language design.
Fortran functions correspond to "pure" functions in C/C++ and other languages, i.e. idempotent functions that do not modify arguments or global variables.
If a C/C++ function is converted to Fortran, it must be rewritten as a subroutine, unless it is a pure function.
Not all C/C++ compilers support the language extension of marking functions as pure, and even with such compilers many programmers are lazy, so they forget to mark as pure the functions where this is applicable, even if this is recommended for improving program optimization and verification.
This is nonsense. Fortran functions aren't pure. They can have side effects.
HPF/Fortran '95 added the PURE attribute for subprograms, but it's not the default.
Many C/C++ compilers, e.g. gcc, support language extensions allowing functions to be marked as pure. This is always recommended where applicable, for better program optimization.
This difference is much more important than the fact that subroutines do not return a value.
Many of the "functions" of C/C++ must be written as subroutines in Fortran, with an extra argument for the result.
The functions of Fortran are what would be called pure functions in C (which can be marked as such with compilers that support C language extensions, like gcc).
The pure functions cannot modify any of their arguments or any global variable, so they are idempotent, which is important in program optimization.
One can explicitly declare a function (or subroutine) to be PURE in Fortran, but it is not the default and never has been.
https://en.wikipedia.org/wiki/Plankalk%C3%BCl
Some Fortran II conventions like the arithmetic IF are now deprecated, but `--std=legacy` is all it takes to make it compile today.
0 - https://en.wikipedia.org/wiki/EBCDIC
(I considered JAX, but the code in question was not amenable to a compute graph. Another option was to thread by fork, and use IPC.)
I liked the language itself more than expected. You have something like "generics" with tensors. Suppose you pass a parameter, N, and you also would like to pass a tensor, and you would like to specify the tensor's shape (N, N). You can do this; the parameter type constraints can reference other parameters.
Tensors and various operations are first-class types, so the compiler can optimise operations easily for the system you're building on. In my case, I got 80% improvement from ifx over gfortran.
Invocation from Python was basically the same as a C library. Both Python and Fortran have facilities for C interop, and Numpy can be asked to lay out tensors in a Fortran compatible way.
Part of what eased the port was that Numpy seems to be a kind of "Fortran wrapper". The ergonomics on tensor addressing, slicing and views is identical.
It also helps that Fortran compatibility is a must for pretty much anything that expects to use BLAS.
I wouldn't call multi-dimensional arrays tensors though. That's a bit of a bastardization of the term that seemed to be introduced by ML guys.
It wasn't until I started using Fortran that I realized how similar it is to BASIC which must have been a poor-man's Fortran.
If you didn't have vectors, Maxwell's equations would spill all over the place. Tensors on the other hand are used in places like continuum mechanics and general relativity where something more than vectors are called for but you're living in the same space(/time) with the same symmetries.
What do you mean, "would": they did! :) The original equations had 20 separate equations, although Maxwell himself tried to reformulate them in quaternions. But if you look e.g. at works of Lorentz, or Einstein's famous 1905 paper, you'll see the fully-expanded version of them. The vector form really didn't fully catch until about the middle of the XX century.
Intel and Nvidia are both offering both C and Fortran compilers, so I was looking at both. I know C well but I decided to not look at it as a presumed default.
When I used C like this in the past, the intrinsics were very low-level, e.g. wrapping specific Altivec or SSE instructions or whatever. I see see it has OpenMP intrinsics, though, which I’m sure I’ll try later.
If I use a library, I’m breaking up the operations and don’t give the optimizing compiler an opportunity to take operations into account together.
With Fortran, I can give the operations directly to the compiler, tell it the exact chip I’m working with and it deals with it.
It would be fun, when I have some time, to go rewrite it in C and see how it compares.
You can do that, and it might be cleaner and less lines of code that way.
But you don't necessarily need to pass the array dimensions as a parameter, as you can call `size` or `shape` to query it inside your function.
At the time everyone seems to default to using C instead. But Fortran is so much easier! It even has slicing notations for arrays and the code looked so much like Numpy as you say.
https://en.wikipedia.org/wiki/Jacquard_machine
* Nothing wrong with that as a reason, of course
0 - https://docs.open-mpi.org/en/main/developers/bindings.html#f...
Fortran in Modern Scientific Computing: An Unexpected Comeback - https://medium.com/@stack1/fortran-in-modern-scientific-comp...
5 Reasons Why Fortran is Still Used - https://www.matecdev.com/posts/why-fortran-still-used.html
Is Fortran better than Python for teaching the basics of numerical linear algebra? - https://loiseaujc.github.io/posts/blog-title/fortran_vs_pyth...
The trickiest part of really learning Fortran today is that it is hard to define what the language is, apart from the practical definition imposed by what its seven or so surviving compilers accept and how they interpret it. There are near-universally portable features that are not part of the ISO standard; there are standard features that are not at all portable, or not available at all anywhere. So what one should know as “Fortran” is its reasonably portable intersection of features across multiple compilers, and there isn’t a good practical book that will teach you that.
1 - https://numerical.recipes/
Pretty much sums up this one. Can't say that I agree if/select/stop are "modern" features.