Celebrating 70 Years of Fortran
fortran-lang.orgIt is a log time since I did any FORTRAN. Maybe they improved it?
FWIW, I started programming in 1965, in FORTRAN II.
Algol, Pascal, Oberon, Simula, ADA, Julia (afik)
It beats LISP by a year and COBOL by two years.
“I used to be a mathematics professor. At that time I found there were a certain number of students who could not learn mathematics. I then was charged with the job of making it easy for businessmen to use our computers. I found it was not a question of whether they could learn mathematics or not, but whether they would. […] They said, 'Throw those symbols out—I do not know what they mean, I have not time to learn symbols.' I suggest a reply to those who would like data processing people to use mathematical symbols that they make the first attempt to teach those symbols to vice-presidents or a colonel or admiral. I assure you that I tried it.” — Grace Hopper
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).
Many years of FORTRAN. Followed by many years of Fortran.
Having said that, so many foundational libraries were implemented in Fortran (BLAS, LINPACK/EISPACK, LAPACK, MINPACK, FISHPACK, FFTPACK, etc.) - thanks for that.
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.
I dimly remember the reason for it not being recursive by default was it didn’t put local variables on the stack, and I guess /RECURSIVE (which I don’t remember) controlled that. Probably there was some SYSGEN parameter which limited stack size. There were people who would declare giant arrays as locals rather than putting them in named COMMON, so the user-friendly compiler default was to put them in a fixed PSECT because those same people would never be using recursion.
It was frustrating that, 30 years after Fortran 77, professors were insisting in writing in that dialect. Thank God I escaped that hell.
Edit: Since people don't understand my point - I'm well aware of the existence of newer Fortran standards. But in much of academia, the professors insisted on sticking with Fortran 77.
In over a decade in academia, I found only one person writing Fortran 90 (this was in 2001). He did it because he didn't tell his advisor he was doing it.
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.
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.
Growing up on early micros, with BASIC, my father had Fortran for the TRS-80.
I took a stab at learning it, but the documentation was reference for calling the compiler, not so much learning the language. And when I found a FORTRAN book, it was quite dated and talking about things like tapes and punches and what not.
So, that effort stalled.
But, my first quarter in college, I took a FORTRAN (77) class. FORTRAN taught on the schools CDC Cyber mainframe.
This was quite a change from 8-bit PET BASIC.
But, most importantly, it was exposure to much of the same concept that an 8-bit computer has, but from a different tact.
This gave me more of a way to view things from a higher level, since I had to make them fit the two different views of how FORTRAN looked at things, how the Cyber presented things, and how BASIC and the PET were "same thing only different".
It also gave me access to a multi-user system, and all of the interesting capabilities it offers.
I remember when they put in their first lab of PCs, and how they started teaching folks Turbo Pascal on micro computers, and I just felt that the users were missing out on a bigger world. "Anyone" can access a PC or micro computer at home, but mainframe or multi user mini access, not so much. It's just a much bigger world out there, and we tend to baby duck what we first see.
Different world today, never had to use FORTRAN professionally, but I am most grateful for the experience of learning it and its environment. Very powerful medium for broader learning.
Also FORTRAN was the only notable computer thing I had "taught" to me (outside of my 20 minute introduction to BASIC by my high school teacher), pretty much everything else I self learned from books and such, even knowing the bulk of it before taking classes in school.
I worked with a proprietary jet engine analysis software suite written in Fortran 77 and It felt very primitive, albeit fast.
Today I feel like C is a much better choice for speed and readability.
If you really need the fastest performance I dont think Fortran gives that much of an advantage writing assembly.
We found it best to to the front-end and I/O of the code in C and the compute in Fortran. Fastest calculations especially with those tailored libraries.
Modern Fortran has pretty serviceable support for array programming.
I believe Alan Kay used to say the right perspective is worth 80 IQ points. We should always strive to broaden our experiences and horizons. We get a ton of wrong perspectives, but one perspective you acquired will be a perfect fit for that thing nobody else has the right experiences to figure out immediately.
It was a very bare-bones language, felt more like a high-level assembly macro language. One thing it did well was expressing formulas with the usual "mathematical" notations (+,-,*,/, parentheses to group operations, variables). I guess this was revolutionary at the time. But the control structures were very limited, everything was basically jumps and gotos. The IF was merely a syntactic sugar for conditional jumps. Of course, functions did not exist in the language.
Its name stands for “Formula Translation,” after all.
> I guess this was revolutionary at the time.
Yes. There was some prior art, but Fortran was the first “mainstream” (for the time) language to offer anything like this.
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!
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.
After learning Pascal I thought fortran was definitely strange and moved on, never to touch it again
It just seems so much work. Pascal was a breath of fresh air.
My first project there was removing all of the Hollerith from the code. Since Fortran predated strings, you had to manipulate them as integers. When you tied that to the original Fortran dynamic memory system, Dynosour, which used equivalenced arrays as pointers, it was a disaster.
It also gave me an appreciation for JavaBeanFactoryFactory. The original Fortran limited identifiers to six characters, the first of which indicated whether the variable was an integer, logical (bool), or real (float). I will take a 100 character name over ILBNK1 every single time.
GOTOs were surprisingly not a big problem, but structured code is definitely a bit easier to read, especially since it brought the practice of indentation with it.
Overall, it was a great experience but I wouldn't want to do it again, even if the work was interesting.
E3SM [0] is still maintained today, and somewhere around 2mil LoC of F90.
Modern Fortran has a lot of niceties that it brings to the table.
[0] https://e3sm.atlassian.net/wiki/spaces/DOC/overview | https://github.com/E3SM-Project/E3SM
If nothing else, short variable names create an incentive to keep functions small enough you can easily figure out what ILBNK1 means.
The best part is that the code was originally punched onto cards, so most of the early code's comments and documentation were on paper in filing cabinets, if you could find them.
My favorite is SimpleBeanFactoryAwareAspectInstanceFactory
https://docs.spring.io/spring-framework/docs/current/javadoc...
I've been away from that world for a while, but still.
At least it was the "Simple" version. LOL.
I can't find anything about this online except for this comment. What does it refer to?
You call into C or assembly to reserve memory and return an out-of-bounds index to a global one member array. That index is generated from the pointer to the new memory as an offset.
You may have had trouble finding it since I misspelled DYNOSOR (no U).
There's a lot of classic old school FORTRAN stuff from the 1950s that still exists albeit ported forwards.
In the nuclear DOE domain its more likely to be encoded decay tables of daughter products for coarse statistical back of envelope (with 1950s computation) guesstimates.
It wasn't until much later the US decided it could stop physical testing (above / below ground detonations) and move to sufficiently scaled and detailed digital nuclear simulations.
the real test will be on the longevity side.
My implementation was based on David Rogers' "Procedural Elements for Computer Graphics", one of only two texts available on 3D graphics, the other being Foley and VanDam.
I remember managing my own stack in a language which didn't support recursion. I learned a lot. Good times.
[0] https://medium.com/@kaveh808/8-summer-at-xerox-in-24-bit-col...
I really enjoy CHM's oral histories. I'm slowly working my way thru all of them and there are some real gems in there (Ken Thompson, Dennis Ritchie, Margaret Hamilton, Gordon Moore, Fred Brooks, John Warnock, etc).
Saddest case was a PhD student in chemical engineering near the end of his thesis work struggling to get reproducible results. After half an hour of debug I realised he was using un-initialised Fortran array state for his data. I suspect his discovery went up in smoke.
Everyone who has used it also has horror stories though. It is a very old language and sometimes artifacts pop up. One time I was parallelizing some older code and ran into an infuriating bug where it seemed like some boundary conditions just weren't being passed properly. There were no compiler errors or warnings. Some MPI commands were simply being ignored, but not others. It turned out that the jank-ass compiler I was using for the project had decided to go into Fortran-77 mode (without saying anything) and stripped them out in the precompiling stage (without saying anything) if they were longer than the 72 character limit that Fortran-77 had. I was coding on a computer new enough to have no CD or DVD drive, but was running into the character limit of a 60's punch card system without knowing it!
PS: The book creates a tsunami calculator and evolves it by adding Modern Fortran features chapter by chapter.
Bill Sky the Fortran guy on Youtube is another very elementary but excellent presentation.
There is an increasing amount of material out there and the people on Fortran Discourse are very knowledgeable and helpful.