However what still makes it a great choice is that it still a relatively simple language compared to C, and maps mathematical formulas to code very well. Inelegant code will still run reasonably fast (which is not the true with C) - so all of these points make it actually a good language when the program is being written by domain experts (i.e., scientists) rather than professional programmers or software engineers.

I have heard that Fortran is very very good at optimizing array processing due to lack of aliases. That may be one answer today. There’s also value in continuity: in using a language for your task because it can build on what others have built. That applies to any established language, of course… but I could see it reasonably applied if someone wrote some kind of numerical processing library today. They’d write it in Fortran and call it from Python!

It is easy to laugh but C programmers have demonstrated that they can't handle variable-sized buffers on the stack, malloc(), free() and all that.

Early versions of FORTRAN [2] didn't even have a stack, like you couldn't write recursive functions, the program would take parameters for array sizes when it boots and the memory layout would all be figured out at the beginning. When I was developing a display controller for persistence of vision displays for the AVR-8 it drove me nuts how the C compiler kept moving the stack pointer around all the time for no real reason when an assembly program could move data to and from statically allocated structures. [3]

FORTRAN and COBOL came out around the time Syntactic Structures did so of course there was not an established theory for how to parse grammars, no parser generators, etc. No Dragon Book, but the heroic techniques used to develop compilers in that age are legendary if not quite lost.

I wrote some FORTRAN programs in high school on a VAX, in a comparative programming languages class in college, converted a lot of FORTRAN algorithms into statically allocated Java in grad school in 1990 and in my postdoc I wrote a generator that wrote JNI bindings for LAPACK.

[1] ... e.g. the typical struct is < 4096 bytes

[2] before the FORTRAN 90 standard though you could set the /RECURSIVE flag on DEC FORTRAN

[3] we were done such a disservice by all those "it's so elegant to compute Fibonacci in a better programming language than BASIC" articles in Creative Computing because recursion is one of those things, like C's memory management, that most programmers can't really handle.

It beats LISP by a year and COBOL by two years.

I used modern Fortran in undergrad and grad research from 2011 to about 2015. I rarely ever encountered FORTRAN 77 back then, and never had to write any. I worked as an intern at NIST and LANL during that time too and it was modern Fortran there as well. At NIST, as far as I'm aware, that group had been using modern Fortran for probably a decade or more before I started in 2011.

I didn't have to write any FORTRAN 77 until 2025 in my current job when I was given a legacy code to work with.

Apparently not. Fortran 90 standard was published 35 years ago, in 1991. But a majority of comments in this thread are about FORTRAN 77. It's like the last 35 years didn't happen at all.

When I first started, with BASIC, my variable of choice was T simply because it was easy to type NEXT T in the FOR loops (why not R? I dunno...T just stuck).