Celebrating 70 Years of Fortran(fortran-lang.org) |
Celebrating 70 Years of Fortran(fortran-lang.org) |
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!
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.
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.
FWIW, I started programming in 1965, in FORTRAN II.
Algol, Pascal, Oberon, Simula, ADA, Julia (afik)
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.
“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
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.
the real test will be on the longevity side.
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).
It is a log time since I did any FORTRAN. Maybe they improved it?
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.
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
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.
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.
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.
Gnnnnnnaaaaaaaaaaaaaa!!!!!
Online conversation about Fortran is invariably domniated by people who waffle about Fortran 77, FORTRAN and bloody punch cards!
Yet modern Fortran versions are actually rather spiffing. Not to mention they can be used with the old libraries which are utterly bombproof.
There is a reason Fortran is still used for mathmatical modelling. It's simple to use, and you can really trust it.
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).
It was one of the last courses, and we were discussing optimization techniques for matrix multiplication. There were the usual three nested loops and the instructor started talking about memory access patterns and stride through the arrays. He re-nested the loops, showed the improvement in access patterns, and pointed out that the compiler itself could do that automatically. (Not to mention vectorize, etc.)
This was around mid-90's, and it gave me a strong appreciation for the fact that simpler languages can be easier to reason about, transform, and optimize. If I'd spent most of the class wondering why the language was as limited as it was, that one session gave a good explanation why it could be viewed as a strength.
Parallel to all of this, I worked a few summers for a major electric utility company. They had a cluster of Cyber mainframes (Descendents of the CDC 6600) that they used to run the grid in real time. Everything was in Fortran (77?), and the shop had a number of people well versed in the language. I didn't a whole lot of direct experience, but it was interesting to see. One thing I do remember is that the memory/disk layout of the data structures were fixed at build time. They ran quarterly builds to update the layouts to add fields, etc. and made do in the interim. Between the constraints of the language, the hardware limitations, and the need for hard real time requirements, there wasn't a lot of room for flexibility.
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.
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.
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 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.
INTEGER ARR1(10), ARR2(5)
EQUIVALENCE (ARR1(6), ARR2)
ARR2(1) = 10
Here is something that started as a specification of the input format of one particular program-tool. That input format was then cloned and mutated by dozens of me-too program-tools. Eventually that format was able to support an interpretation as a language with its own language-like abstractions. That is astonishing and I think was not on the radar of computing machinery people in the 50s.
I often consider getting back into programming and a few years ago, when I rejoined USENET and started looking around, the Fortran newsgroup `comp.lang.fortran` was active. The community there was as welcoming and supportive as I've met, and I got some interesting info.
I knew FORTRAN 77 and looked at some FORTRAN IV code. Now it's a very different language indeed -- I can't read the modern version at all, it's totally unfamiliar -- but you can still write old-style code in the new language, or mix in some new features in older-style code. It looks pretty good, TBH.
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.
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...
It beats LISP by a year and COBOL by two years.
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.
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.
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.
Apparently, programmers would 'unpunch' a hole in a card by taping some paper back in the hole to save repunching a new card! And sometimes these 'chads' would fall out, making for some interesting debugging.
I learned APL while most of my colleagues were angry for not learning C (or xBase, which was immediately applicable). Had the teacher chosen the commercially appealing option, those students would have never seen how different from the Pascal and Fortran they learned before could be, how conciseness was powerful, and how arrays being first-class citizens made sense.
To this day, I'm frustrated by Excel's (and almost no other spreadsheet's) inability to have a cell containing anything other than a scalar.
When people ask me which language they should learn next, I always suggest something different from what they already know. APL is interesting, Haskell, Lisp, Smalltalk, and FORTH are the ones I like to point people to. Ruby is also interesting - it'll shatter a lot of your certainties about syntax and how syntax should behave.
https://techcommunity.microsoft.com/blog/excelblog/excel-now...
Thankfully I was also blessed both during my high school apprenticeship, and engineering degree, to enjoy a multitude of programming languages and environments, in similar vein to what you describe.
However, and that was the point I was making, there is a difference between being stuck in the old ways, when the professors themselves learnt them as students, and what are common practices using the programming language in modern times.
I wonder when the first FORTRAN 77 linter happened.
> 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
And then to spend a card on a comment line...
Modern Fortran has pretty serviceable support for array programming.
cough S/R cough.
Like, both Numpy and S/R evolved as an interface over Fortran programs for matrix manipulation but S (even R, maybe) signficantly predates Numpy.
Maybe we get restrict in C++35
This kind of code then easily breaks by overflowing the stack if the compiler allocates them there.
But this then doesn't work that well if the procedure is called recursively, or concurrently from multiple threads.
Making this even worse, in a recent Fortran standard (2008?) this was reversed such that procedures must be explicitly marked with NON_RECURSIVE in order to allow the compiler to allocate variables statically. Undoubtedly the right decision given the increasing prevalence of threads as well as recursive algorithms, but a gotcha for compiling old dusty deck code.
If nobody with domain knowledge can understand the program because it's written in a language unfamiliar to them (such as C) with tons of traps and pitfalls (such as C), the value of its contribution to the corpus of knowledge is diminished.