I used to work on software that still uses Fortran from the 50's and is still in maintenance and use today. IIRC, it had ~700kloc of Fortran. It may be the oldest and largest Fortran codebase still in use.
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.
You would think, but that isn't what happened at all. Half the code was very nice and readable but half was giant subroutines doing complex mathematics. The largest subroutine was over 10kloc.
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 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
Besides the short names, common blocks and computed gotos were the bane of my existence maintaining primordial Fortran. My first and intern project was translating a punch card era (early 60s was the best bet) code base that had been textified and could compile in f77. Fortunately I didn’t have to really deal with any strings
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).
Linear Algebra libraries, geomagnetic world models, tidal models, navigation ephemerides, ...
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 Computer History Museum collected an oral history[0] of John Backus[1] and there's some discussion about what computing was like when Fortran was created.
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).
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.
With vector machines, Fortran yielded (much) faster code because (a) there was a whole lot of work on preprocessors for "dusty deck" code and (b) the lack of pointers and their overlap let the compilers do their stuff. C code needed a lot of #pragma's to let it know that some pointers didn't overlap and so could be optimized.
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.
C allowed pointer aliasing, so you always have to refresh reads incase a pojnter modified the value. With any loop, that is just more reads to update dependancies every cycle. When not aliased, you cache value in register. Much later C introduced “restrict” keyword to match fortran performance code. c++ is still fighting this by insisting you work with different types, hence by default you dont get aliasing but that doesnt cover 100% of scenarios.
Fortran had arrays since the beginning, but it wasn't really for "array-based programming" except in a trivial sense, since expressions could not produce arrays. APL is the language that invented first-class arrays, and is far more advanced at it than most of its successors, particularly including NumPy.
Modern Fortran has pretty serviceable support for array programming.
Hard disagree that julai perfected arrays. I love Julia but even compared with old with old “array programming lenguaje” like APL not even mentioning newer ones like BQN. Julia array still seem a less expressive than one might hope.
There’s also an under explored area of compile time Shape Type checking which there has been interesting advancements in the Rust space like https://github.com/JErnestoMtz/rapl
Hard disagree that julai perfected arrays. I love Julia but even compared with old with old “array programming lenguaje” like APL not even mentioning newer ones like BQN. Julia array still seem a less expressive than one might hope.
Heh, I used that TRS-80 (microsoft!) Fortran in high school - wrote a library for propagating error bounds and significant figures through calculations, for chemistry lab reports. (Could probably have done it in BASIC too, but I suspect I was looking for an excuse to use fortran for something :-)
> 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.
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 have a lot of fondness for the language. When I was in college, there were a series of three 1-hour language intro courses. (C++, Lisp, and Fortran). I took all three. Lisp is the only one I use these days, but the Fortran class made an impression.
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.
I wrote Fortran for my first job as a software developer in 2018 for simulation solvers. Still like the language! Modern fortran is very very fast and much nicer to use than C for linear algebra. So in my opinion for numerical calculations it remains the best language, even today.
Happy Birthday!
I never used FORTRAN 77 (which I'm grateful for) but I enjoyed using Fortran 95 a few times in the early 2000s. Apart from the I/O stuff which always felt clunky but I was also very inexperienced in those day (now I would just wrap it in a Python library). I did try to use it a couple of years ago for a personal DSP project but had a problem finding libraries that were up to date/modernised and so I didn't get very far. I know that there's fpm now but it was just before that happened, maybe I'll try again.
Used to man the free help desk for programming problems at the uni computing centre I worked at. "Have you got a current listing of the program" got rid of most of them.
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.
I remember helping a research group port some old Fortran code they had to a more modern environment and compiler. Turning on array bounds checking made the program crash pretty quickly. "There can't be a problem with the code as we've published papers with it". Umm, sorry sunshine, that's not how it works.
Circa 2013, one course in our masters program (hydrogeology) allowed us to pick and choose an assignment question. There was a 5000 word essay (can't remember topic) or build flow models using analytical solutions and discuss their limitations. Most people picked the former while I picked the latter. Bugs werent penalised as the ultimate secondary lesson was about "black boxes" and never to rely on numerical model outputs without calculating analytical solutions to verify by hand.
Having written an open source Fortran library (for x ray scattering and absorption in a particular regime so this is fairly “niche” shall we say), genuinely curious: what if any advantages or strengths does Fortran have these days over other language choices? Are there circumstances where it’s arguably the “right” choice?
May I ask: why did you write that library in Fortran? That is, what was your answer to your question at the time you wrote it?
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!
The answer was “my adviser insisted because that’s the language he used”. I had to fight to use Fortran 95 and not 77. So I think like you say value was building on an existing community’s codebase in a language they were familiar with and comfortable with.
Source code is meant to be read, and, occasionally, compiled.
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.
I agree with this and think this is the only argument I’m aware of for real decisions to use of Fortran, which I suppose means its future is doomed with human turnover + ease of porting in these AI days…
A lot of the early, absolute advantages of Fortran (numerical precision, non-aliasing) has been adopted by C.
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.
As @jleyank pointed out, the more restrictive semantics of Fortran prevent expressing things the compiler can't optimize. A Fortran compiler can make assumptions about code flow and memory accesses a C compiler can't, and, therefore, can optimize the code further than a naive C implementation could be optimized.
I mean, I think it's best in class in its niche: writing numerical algorithms that compile to highly optimized machine code, while being reasonably readable and intuitive (at least from F90 on). It's arguably still the easiest way to write compute-intensive numerical extensions for python (well, if it's single-threaded, and if numpy can't do it, and if you're not using GPUs ...).
One of my favorite stories was my walking past a PhD math guy agonizing over a bug in his massive Fortran code. The print out was two inches thick. I made my usual comment, not even slowing my pace as I walked by his desk…. something like: that comma looks like it is in column 80 on your list of passed arguments. Well, that was his bug and I think I forever got more respect from him than I ever deserved.
I started off programming in FORTRAN in my first job, 40 years ago. There was a lot of terrible stuff in FORTRAN from a software engineering point of view: COMMON blocks, GOTOs, ENTRY points (to enter a subroutine part way through!), but it was one of the first high level language and language designers had a lot to learn.
At some point I was quite interested in how the very first version of FORTRAN looked like, so I wrote a FizzBuzz [1] in it.
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.
My first job programming was in a geophysics lab. I had to read fortran 77 codes and write in some slightly more modern variant (I can't remember now which). They were simulating the Earth's mantle and used it because it was fast.
An ex got me "A Fortran Coloring Book" years ago while I was working with astronomers. I was still in grad school and it gave me an excuse to learn it.
In the mid 90s I used Fortran to model a distillation column in a chemical engineering plant. Here I read that it is still the go to language for nuclear engineering. I am amazed but for some reason happy about this.
You know, I have read this a lot. But the Programmer's Reference Manual, dated October 15, 1956 clearly has it as Fᴏʀᴛʀᴀɴ, which used "small caps", so I am not so sure anymore.
I wanted to learn Fortran in the 1990s and borrowed a Fortran book from the university library. On the first or second page it stated "To mark comments, just punch a letter 'C' into the first column of the punch card." I returned the book and never learned Fortran.
Having said that, so many foundational libraries were implemented in Fortran (BLAS, LINPACK/EISPACK, LAPACK, MINPACK, FISHPACK, FFTPACK, etc.) - thanks for that.
Mainframe-era systems often used fixed-size or limited-size buffers and data structures, based on those 80-character punched cards, most addressing modes on the 360 add 12-bit immediate displacements to pointers held in registers [1] bytes and such.
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.
Fortran (before 90) ignored characters after column 72 because the IBM 704 had a 36-bit word and read each row of a card into two words. (The card reader could be wired with a plugboard to select any 72 of 80 columns from the card.)
DEC VAX/VMS Fortran 77, ca. mid-1980s, did use the process stack for call, return and arguments; all the compilers DEC supplied on that platform did, because there was a common calling sequence among all the languages and you could call any language from any other.
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.
To this day some Fortran compilers put large local variables into static storage rather than the stack. Because many old Fortran programs were written with the assumption that all procedure variables were statically allocated, and thus having huge arrays as local variables wasn't an issue.
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.
I remember working with a guy who had programmed in FORTRAN in the days of punch cards. He said he once dropped the stack of cards and had to reconstruct the order. He always numbered the cards after that.
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.
It was good practice to draw a diagonal line across the top of a card deck with a magic marker, so that a dropped deck could be manually sorted easily.
One of the most "fun" things with Fortran is the EQUIVALENCE stmt. It specifies that two variables share the same memory, even if they are different types. You can also do array equivalences, so:
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 studied Fortran at university (1985-1988) and got a first in that course module. I quite enjoyed it.
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.
Right out of college, I wrote my first ray tracer in Fortran in the mid-80's at the Xerox Research Centre of Canada. I remember the setup being a VAX 11/750 with a RasterTech color monitor (512x512 if memory serves). [0]
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.
Happy birthday! I think this has to be the oldest programming language still in use. 70 years is quite an eternity in the sphere of computing. Before Fortran, there was (almost?) nothing but assembler and plug board connectors.
And Fortran doesn’t just predate Lisp, it’s a direct ancestor. McCarthy was talking about LISP as a FORTRAN extension for quite a while during LISP’s development. The original Fortran is effectively LISP 0.
It's 30 years since I last used Fortran to pass my Civil & Structural Bachelor's and Masters. Loved the simplicity of it, modelling spring stiffness in concrete and steel piles hammers into the ground and tie rods being pulled out of their grout anchors. However, what blows my mind is that something I did on a 386/ 486 as a 3-6 month research degree is now modelled by AI and run on my desktop in minutes.
My second university co-op placement, which led to my first real job of 16 years, included writing a FORTRAN 77 compiler front end. It's crazy by modern standards; in some cases you have to see as far as the second-last character of a multi-line statement to determine what kind of statement it is.
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.
They knew Fortran 77 and didn't want to learn Fortran 90+. I think they also had compatibility concerns. Unsure if there are any, though.
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.
The goal of college is not to prepare you to join the workforce - it's to make you learn the concepts under the code you'll read or write when working in the industry. In that, forced constraints are useful.
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.
I agree that the role is to learn concepts and such, however there is a big difference in how far from the industry some teachers are.
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.
Many “standard” features are not completely portable, since their specifications are ambiguous, incomplete, not validated by prototype implementations, and not enforced by public test suites. This makes Fortran compiler development hard; should each feature in a new compiler be compatible with existing compilers, or with the language in the ISO standard? And when the ISO committee changes semantics or breaks long-standing guarantees of the language like the integrity of parentheses, should a compiler break code?
I had a similar experience about ten years ago at a German university and I don't get it either. However, I did not dare ask why at the time, as I did not want to start a discussion with a potentially vengeful professor.
Even if that were true, which I doubt, there was nothing in your comment to indicate that, and in fact it contradicted it ... if you were aware, then it's nonsensical to ask whether people have moved on. It's well known that Fortran 90 was a major advance over Fortran 77 and that of course people moved on.
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.
A not very well known fact: older versions of the numpy python library still require Fortran for its build process. I think newer versions don't need the GNU Fortran compiler any longer.
People sometimes scoff at computing languages as old as Fortran, but they should realize Fortran has remained relevant because it's still really good at what it does. It's syntax for mathematical operations is head and shoulders above most more recent languages. It's fast and offers great control of the hardware too. Even today, if you want to write a numerical simulation that's heavy on the math and hard on the hardware, Fortran should be considered.
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!
I’m still amazed that the first dozen programs I ever wrote back in 1963 for an IBM 7090 (or 7094) ran first time. (They were trivial programs). I’m also still pissed that I never got to debug the 13th, in FAP (Fortran Assembly Program), which had a minor syntax error – a comma instead of a period, or vice versa. NASA had just launched a weather satellite, which monopolized computer time, leaving zero minutes for high school students.
FORTRAN is also the origin of using 'i', 'j', 'k', etc as loop variables in code, since 'i' was the first variable name that could be used for that purpose. The original language design was constrained by very primitive computers.
The reason 'i' was the first letter available was because by default identifiers starting with, I think, I-N were integers instead of float.
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).
Is that really true, if so, what's your basis? Fourier used i for the same purpose, and it definitely became a pretty standard indexing variable long before the 1950s.
Most early code written in FORTRAN was essentially just transcribing formulae and algorithms that already would use such variable names.
The original language design was constrained by primitive thinking and lack of experience. The nature of computers in 1957 had no bearing on such things as variable names starting with I-N being implicitly integers ... that followed existing mathematical practice.
"that followed existing mathematical practice". Not what I would call primitive thinking. It set out to handle math quickly and it succeeded. I/O wasn't its strength, and I'm sure the latest versions look like verbose C.
I'm from Norway and as many may already know, we are above average curious about what happens out in the sea - because of oil mainly. There is a lot of research and simulations and stuff going on in that field, and most of that is still based on Fortran.
I remember a piece called SPAG (I think) that could turn FORTRAN spaghetti code (with lots of GOTOs) into relatively clean, structured code. It was very useful.
I don't see why. LISP is just a year younger and COBOL is 2 years younger. And Algol, spawned a year after FORTRAN, is no longer used as such (although there is now GCC support for Algol 68) but spawned many "Algol-like" languages, including most of the languages used today ... and even modern Fortran can be considered "Algol-like", having evolved to include its block structure.
FWIW, I started programming in 1965, in FORTRAN II.
I think the idea is that blas + lapack are still at the foundation of basically the whole stack. Back in the day (or at least when I last looked), numpy was very much built on of them, and the rest of the data science stack was built on top of numpy. No idea how much these things are still the case.
“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
The company I work for, has a subscription to O'Reilly. While searching for something "side", unrelated to day by day job, I ran across the beautiful book "Modern Fortran". The Fortran in the book (2008+ standard)is very different from the clumsy lectures of F77. It is a beautiful language. I'm sold.
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.
FORTRAN 77 was the language for the first programming language course I took. I absolutely hated computers and programming after that course. Later I took CS courses and used Pascal -- one day the concept of abstraction hit me as we were developing data structs in the 2nd semester and the light went on. That is when I first started to love programming. FORTRAN was thereafter referred to as the F language. Sorry to be a bummer, but I still recoil when I hear about that language.
Horray! I'm partial, of course, to Fortran 77 and until very recently, still used it. Mostly taking consulting jobs moving it to Matlab or Numpy and verifying it.
I believe it has changed quite a lot, keeping its focus for scientific/engineering computing, but adapting more modern language constructs. I'm not sure how much of the archaic stuff (COMMON blocks, ENTRY points etc) is supported in the more recent standards for backward compatibility.
Aren't COMMON's implemented as static structures? Stuff that's accessible from multiple functions - except that Fortran requires explicit rather than implicit reference.
It is way of sharing variable values without using parameters. But it is ugly and easy to make errors, e.g. accidentally missing a variable out of the middle of the list in one function or subroutine means all the later variables have unexpected values.
It is a log time since I did any FORTRAN. Maybe they improved it?
COMMON, ENTRY, and EQUIVALENCE are certainly frowned upon in modern Fortran style, as the language has gotten less error prone ways of accomplishing the problems those features ostensibly solved. But they still exist in the language for backwards compatibility.
Sadly no. BLAS/LAPACK are written in Fortran and they are the core of Numpy for Python and several other packages. Megafast number crunching it's mainly the #1 feature of Fortran. Just K can be on par and, well, it's propietary and even if it shines by itself doing calculations on vectors, integrating it with libre projects it's both impossible license wise and from a practical point, even if K was free.
I used to work on software that still uses Fortran from the 50's and is still in maintenance and use today. IIRC, it had ~700kloc of Fortran. It may be the oldest and largest Fortran codebase still in use.
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.
That certainly might be one of the oldest Fortran codebases still in use I've heard of, but not quite the largest. (Character came in '77 wasn't it?)
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
> It also gave me an appreciation for JavaBeanFactoryFactory
If nothing else, short variable names create an incentive to keep functions small enough you can easily figure out what ILBNK1 means.
You would think, but that isn't what happened at all. Half the code was very nice and readable but half was giant subroutines doing complex mathematics. The largest subroutine was over 10kloc.
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.
> The largest subroutine was over 10kloc.
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...
>It also gave me an appreciation for JavaBeanFactoryFactory.
My favorite is SimpleBeanFactoryAwareAspectInstanceFactory
WOW. I went googling, sorta hoping this was a joke, but nope, there it is:
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.
Also love AbstractSingletonProxyFacgoryBean
How about ReflectiveProcessorBeanFactoryInitializationAotProcessor?
Besides the short names, common blocks and computed gotos were the bane of my existence maintaining primordial Fortran. My first and intern project was translating a punch card era (early 60s was the best bet) code base that had been textified and could compile in f77. Fortunately I didn’t have to really deal with any strings
Removing Hollerith refers to the way strings were originally written in Fortran: https://en.wikipedia.org/wiki/Hollerith_constant
> the original Fortran dynamic memory system, Dynosour
I can't find anything about this online except for this comment. What does it refer to?
Here's a link to one of the papers: https://dl.acm.org/doi/10.1145/954654.954661
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).
Nuclear weapons simulation?
Linear Algebra libraries, geomagnetic world models, tidal models, navigation ephemerides, ...
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.
> I used to work on software that still uses Fortran from the 50's
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.
Fortran was the most portable language before C, so people wrote compilers in it. Using Hollerith character constants.. and without strings..
The Computer History Museum collected an oral history[0] of John Backus[1] and there's some discussion about what computing was like when Fortran was created.
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).
[0] https://www.youtube.com/watch?v=dDsWTyLEgbk
[1] https://en.wikipedia.org/wiki/John_Backus
There's also Backus' "Programming in America in the 1950s – Some Personal Impressions" talk https://www.youtube.com/watch?v=EylBknGtkqA at the 1976 First International Research Conference on the History of Computing. The conference paper is pp. 125-135 https://archive.org/details/historyofcomputi0000inte/page/12... in A History of Computing in the Twentieth Century (1980, Metropolis, Howlett and Rota eds., ISBN 0-12-491650-3 ). Naturally it also got a session at the first History of Programming Languages conference in 1978 https://dl.acm.org/doi/10.1145/960118.808379 at which Backus spoke again https://dl.acm.org/doi/book/10.1145/800025#sec2 . And of course it's one of the stars of Jean Sammet's 1969 Programming languages: history and fundamentals book (ISBN 0137299885) where the FORTRAN section begins on p. 143 https://archive.org/details/programminglangu00unse/page/143/... .
FORTRAN was a very important language for me.
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.
Fortran while historically important doesn't really seem like a good choice today.
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.
With vector machines, Fortran yielded (much) faster code because (a) there was a whole lot of work on preprocessors for "dusty deck" code and (b) the lack of pointers and their overlap let the compilers do their stuff. C code needed a lot of #pragma's to let it know that some pointers didn't overlap and so could be optimized.
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.
C allowed pointer aliasing, so you always have to refresh reads incase a pojnter modified the value. With any loop, that is just more reads to update dependancies every cycle. When not aliased, you cache value in register. Much later C introduced “restrict” keyword to match fortran performance code. c++ is still fighting this by insisting you work with different types, hence by default you dont get aliasing but that doesnt cover 100% of scenarios.
Maybe we get restrict in C++35
Fortran invented array-based programming, which arguably numpy advanced and now Julia finally perfected
Fortran had arrays since the beginning, but it wasn't really for "array-based programming" except in a trivial sense, since expressions could not produce arrays. APL is the language that invented first-class arrays, and is far more advanced at it than most of its successors, particularly including NumPy.
Modern Fortran has pretty serviceable support for array programming.
> which arguably numpy advanced and now Julia finally perfected
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.
Hard disagree that julai perfected arrays. I love Julia but even compared with old with old “array programming lenguaje” like APL not even mentioning newer ones like BQN. Julia array still seem a less expressive than one might hope.
There’s also an under explored area of compile time Shape Type checking which there has been interesting advancements in the Rust space like https://github.com/JErnestoMtz/rapl
Hard disagree that julai perfected arrays. I love Julia but even compared with old with old “array programming lenguaje” like APL not even mentioning newer ones like BQN. Julia array still seem a less expressive than one might hope.
There’s also an under explored area of compile time Shape checking, that might open up a new era in array. There has been interesting advancements in the Rust space like https://github.com/JErnestoMtz/rapl or https://github.com/chelsea0x3b/dfdx
Heh, I used that TRS-80 (microsoft!) Fortran in high school - wrote a library for propagating error bounds and significant figures through calculations, for chemistry lab reports. (Could probably have done it in BASIC too, but I suspect I was looking for an excuse to use fortran for something :-)
> 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.
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 have a lot of fondness for the language. When I was in college, there were a series of three 1-hour language intro courses. (C++, Lisp, and Fortran). I took all three. Lisp is the only one I use these days, but the Fortran class made an impression.
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.
I wrote Fortran for my first job as a software developer in 2018 for simulation solvers. Still like the language! Modern fortran is very very fast and much nicer to use than C for linear algebra. So in my opinion for numerical calculations it remains the best language, even today. Happy Birthday!
I remember being excited when the complex number type was added in Fortran 77. Good times.
I never used FORTRAN 77 (which I'm grateful for) but I enjoyed using Fortran 95 a few times in the early 2000s. Apart from the I/O stuff which always felt clunky but I was also very inexperienced in those day (now I would just wrap it in a Python library). I did try to use it a couple of years ago for a personal DSP project but had a problem finding libraries that were up to date/modernised and so I didn't get very far. I know that there's fpm now but it was just before that happened, maybe I'll try again.
Used to man the free help desk for programming problems at the uni computing centre I worked at. "Have you got a current listing of the program" got rid of most of them.
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.
many such cases
I remember helping a research group port some old Fortran code they had to a more modern environment and compiler. Turning on array bounds checking made the program crash pretty quickly. "There can't be a problem with the code as we've published papers with it". Umm, sorry sunshine, that's not how it works.
Circa 2013, one course in our masters program (hydrogeology) allowed us to pick and choose an assignment question. There was a 5000 word essay (can't remember topic) or build flow models using analytical solutions and discuss their limitations. Most people picked the former while I picked the latter. Bugs werent penalised as the ultimate secondary lesson was about "black boxes" and never to rely on numerical model outputs without calculating analytical solutions to verify by hand.
Having written an open source Fortran library (for x ray scattering and absorption in a particular regime so this is fairly “niche” shall we say), genuinely curious: what if any advantages or strengths does Fortran have these days over other language choices? Are there circumstances where it’s arguably the “right” choice?
May I ask: why did you write that library in Fortran? That is, what was your answer to your question at the time you wrote it?
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!
The answer was “my adviser insisted because that’s the language he used”. I had to fight to use Fortran 95 and not 77. So I think like you say value was building on an existing community’s codebase in a language they were familiar with and comfortable with.
Source code is meant to be read, and, occasionally, compiled.
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.
I agree with this and think this is the only argument I’m aware of for real decisions to use of Fortran, which I suppose means its future is doomed with human turnover + ease of porting in these AI days…
A lot of the early, absolute advantages of Fortran (numerical precision, non-aliasing) has been adopted by C.
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.
As @jleyank pointed out, the more restrictive semantics of Fortran prevent expressing things the compiler can't optimize. A Fortran compiler can make assumptions about code flow and memory accesses a C compiler can't, and, therefore, can optimize the code further than a naive C implementation could be optimized.
I mean, I think it's best in class in its niche: writing numerical algorithms that compile to highly optimized machine code, while being reasonably readable and intuitive (at least from F90 on). It's arguably still the easiest way to write compute-intensive numerical extensions for python (well, if it's single-threaded, and if numpy can't do it, and if you're not using GPUs ...).
One of my favorite stories was my walking past a PhD math guy agonizing over a bug in his massive Fortran code. The print out was two inches thick. I made my usual comment, not even slowing my pace as I walked by his desk…. something like: that comma looks like it is in column 80 on your list of passed arguments. Well, that was his bug and I think I forever got more respect from him than I ever deserved.
I started off programming in FORTRAN in my first job, 40 years ago. There was a lot of terrible stuff in FORTRAN from a software engineering point of view: COMMON blocks, GOTOs, ENTRY points (to enter a subroutine part way through!), but it was one of the first high level language and language designers had a lot to learn.
At some point I was quite interested in how the very first version of FORTRAN looked like, so I wrote a FizzBuzz [1] in it.
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.
[1] https://mveg.es/posts/fizzbuzz-in-fortran-1/
> One thing it did well was expressing formulas
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.
My first job programming was in a geophysics lab. I had to read fortran 77 codes and write in some slightly more modern variant (I can't remember now which). They were simulating the Earth's mantle and used it because it was fast.
An ex got me "A Fortran Coloring Book" years ago while I was working with astronomers. I was still in grad school and it gave me an excuse to learn it.
In the mid 90s I used Fortran to model a distillation column in a chemical engineering plant. Here I read that it is still the go to language for nuclear engineering. I am amazed but for some reason happy about this.
More precise:
Many years of FORTRAN. Followed by many years of Fortran.
You know, I have read this a lot. But the Programmer's Reference Manual, dated October 15, 1956 clearly has it as Fᴏʀᴛʀᴀɴ, which used "small caps", so I am not so sure anymore.
╭━━━╮╱╱╱╱╭╮ ┃╭━━╯╱╱╱╭╯╰╮ ┃╰━━┳━━┳┻╮╭╋━┳━━┳━╮ ┃╭━━┫╭╮┃╭┫┃┃╭┫╭╮┃╭╮╮ ┃┃╱╱┃╰╯┃┃┃╰┫┃┃╭╮┃┃┃┃ ╰╯╱╱╰━━┻╯╰━┻╯╰╯╰┻╯╰╯
I wanted to learn Fortran in the 1990s and borrowed a Fortran book from the university library. On the first or second page it stated "To mark comments, just punch a letter 'C' into the first column of the punch card." I returned the book and never learned Fortran.
Having said that, so many foundational libraries were implemented in Fortran (BLAS, LINPACK/EISPACK, LAPACK, MINPACK, FISHPACK, FFTPACK, etc.) - thanks for that.
Mainframe-era systems often used fixed-size or limited-size buffers and data structures, based on those 80-character punched cards, most addressing modes on the 360 add 12-bit immediate displacements to pointers held in registers [1] bytes and such.
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.
Fortran (before 90) ignored characters after column 72 because the IBM 704 had a 36-bit word and read each row of a card into two words. (The card reader could be wired with a plugboard to select any 72 of 80 columns from the card.)
DEC VAX/VMS Fortran 77, ca. mid-1980s, did use the process stack for call, return and arguments; all the compilers DEC supplied on that platform did, because there was a common calling sequence among all the languages and you could call any language from any other.
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.
To this day some Fortran compilers put large local variables into static storage rather than the stack. Because many old Fortran programs were written with the assumption that all procedure variables were statically allocated, and thus having huge arrays as local variables wasn't an issue.
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.
I remember working with a guy who had programmed in FORTRAN in the days of punch cards. He said he once dropped the stack of cards and had to reconstruct the order. He always numbered the cards after that.
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.
It was good practice to draw a diagonal line across the top of a card deck with a magic marker, so that a dropped deck could be manually sorted easily.
One of the most "fun" things with Fortran is the EQUIVALENCE stmt. It specifies that two variables share the same memory, even if they are different types. You can also do array equivalences, so:
will also set ARR1(6) to 10.
There is one under-appreciated aspect of Fortran.
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 studied Fortran at university (1985-1988) and got a first in that course module. I quite enjoyed it.
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.
Right out of college, I wrote my first ray tracer in Fortran in the mid-80's at the Xerox Research Centre of Canada. I remember the setup being a VAX 11/750 with a RasterTech color monitor (512x512 if memory serves). [0]
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...
Happy birthday! I think this has to be the oldest programming language still in use. 70 years is quite an eternity in the sphere of computing. Before Fortran, there was (almost?) nothing but assembler and plug board connectors.
https://www.guinnessworldrecords.com/world-records/397792-ol...
It beats LISP by a year and COBOL by two years.
And Fortran doesn’t just predate Lisp, it’s a direct ancestor. McCarthy was talking about LISP as a FORTRAN extension for quite a while during LISP’s development. The original Fortran is effectively LISP 0.
It's only another 30 years before we have the first one hundred years old extant programming language.
That's only a bit less than half an eternity. Programming languages may have been supplanted by vibe slop by then.
It's 30 years since I last used Fortran to pass my Civil & Structural Bachelor's and Masters. Loved the simplicity of it, modelling spring stiffness in concrete and steel piles hammers into the ground and tie rods being pulled out of their grout anchors. However, what blows my mind is that something I did on a 386/ 486 as a 3-6 month research degree is now modelled by AI and run on my desktop in minutes.
Well, what happened with your degree? Do you use it?
My second university co-op placement, which led to my first real job of 16 years, included writing a FORTRAN 77 compiler front end. It's crazy by modern standards; in some cases you have to see as far as the second-last character of a multi-line statement to determine what kind of statement it is.
Have people moved on from Fortran 77?
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.
Yes. With Fortran 90 most of the real archaic stuff was already gone. And they keep publishing new standards.
After Fortran 77 came Fortran 90, Fortran 95, Fortran 2003, Fortran 2008, Fortran 2018, and Fortran 2023.
I'm well aware of it. And as late as 2007, I was forbidden from writing those dialects. Professors wanted everything in Fortran 77.
Interesting. Did they explain why?
They knew Fortran 77 and didn't want to learn Fortran 90+. I think they also had compatibility concerns. Unsure if there are any, though.
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.
Basically the same kind of fossilised professors that would teach C89, and C++98 after going through C as prerequisite, in 2026.
The goal of college is not to prepare you to join the workforce - it's to make you learn the concepts under the code you'll read or write when working in the industry. In that, forced constraints are useful.
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.
I agree that the role is to learn concepts and such, however there is a big difference in how far from the industry some teachers are.
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.
As for Excel, I have news for you:
https://techcommunity.microsoft.com/blog/excelblog/excel-now...
Many “standard” features are not completely portable, since their specifications are ambiguous, incomplete, not validated by prototype implementations, and not enforced by public test suites. This makes Fortran compiler development hard; should each feature in a new compiler be compatible with existing compilers, or with the language in the ISO standard? And when the ISO committee changes semantics or breaks long-standing guarantees of the language like the integrity of parentheses, should a compiler break code?
I had a similar experience about ten years ago at a German university and I don't get it either. However, I did not dare ask why at the time, as I did not want to start a discussion with a potentially vengeful professor.
> I'm well aware of it.
Even if that were true, which I doubt, there was nothing in your comment to indicate that, and in fact it contradicted it ... if you were aware, then it's nonsensical to ask whether people have moved on. It's well known that Fortran 90 was a major advance over Fortran 77 and that of course people moved on.
There was a CS literature joke that I saw back in 1982. "Whatever language is used to program high-performance machines, it will be called Fortran.".
> Have people moved on from 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.
Your experience is not universal.
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.
I would demand an IBM 3278 or 3290 terminal to work on that. Or a VT-340.
Fortran 77 should work on any modern machine. A huge amount of Fortran code still being run today is in Fortran 77.
Fortran 77 is the original Python3.
A not very well known fact: older versions of the numpy python library still require Fortran for its build process. I think newer versions don't need the GNU Fortran compiler any longer.
https://numpy.org/doc/1.19/user/building.html
People sometimes scoff at computing languages as old as Fortran, but they should realize Fortran has remained relevant because it's still really good at what it does. It's syntax for mathematical operations is head and shoulders above most more recent languages. It's fast and offers great control of the hardware too. Even today, if you want to write a numerical simulation that's heavy on the math and hard on the hardware, Fortran should be considered.
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!
I learned programming in FORTRAN II on an IBM 1620 in 1965.
Nuts, I was going to post that FORTRAN (IV) was my first programming language, but that was in 1969. So you have me beat!
I’m still amazed that the first dozen programs I ever wrote back in 1963 for an IBM 7090 (or 7094) ran first time. (They were trivial programs). I’m also still pissed that I never got to debug the 13th, in FAP (Fortran Assembly Program), which had a minor syntax error – a comma instead of a period, or vice versa. NASA had just launched a weather satellite, which monopolized computer time, leaving zero minutes for high school students.
I started in 1966 with Fortran II on CDC 3500. Later I spent quality time on the IBM 1800 which has the same instruction set as the 1620.
FORTRAN is also the origin of using 'i', 'j', 'k', etc as loop variables in code, since 'i' was the first variable name that could be used for that purpose. The original language design was constrained by very primitive computers.
The reason 'i' was the first letter available was because by default identifiers starting with, I think, I-N were integers instead of float.
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).
Other way around. I–N were integers rather than float because mathematics convention uses i, j, … as indices and n, m as sizes or counts.
The joke "God is Real (unless declared integer)" is definitely fortran-specific, though :-)
Is that really true, if so, what's your basis? Fourier used i for the same purpose, and it definitely became a pretty standard indexing variable long before the 1950s. Most early code written in FORTRAN was essentially just transcribing formulae and algorithms that already would use such variable names.
i has been the default variable for sum notation in mathematics long before FORTRAN. Here's an example dating from 1838: https://www.numdam.org/item/JMPA_1838_1_3__508_0.pdf
Where in that doc, sorry? I thought I spotted something then realized it may have been a ‘1’.
In equation 9 (and later) for example: Dans ce développement, le terme qui en a i avant lui, a pour expression...
It might actually be the other way round: Fortran adopted the convention that i,j,k are integer variables because that was the standard in maths.
The original language design was constrained by primitive thinking and lack of experience. The nature of computers in 1957 had no bearing on such things as variable names starting with I-N being implicitly integers ... that followed existing mathematical practice.
"that followed existing mathematical practice". Not what I would call primitive thinking. It set out to handle math quickly and it succeeded. I/O wasn't its strength, and I'm sure the latest versions look like verbose C.
origins are very relative, it seems to have [started a bit before](https://stats.stackexchange.com/questions/176965/what-do-i-a...) :D
I'm from Norway and as many may already know, we are above average curious about what happens out in the sea - because of oil mainly. There is a lot of research and simulations and stuff going on in that field, and most of that is still based on Fortran.
Well, some day, they'll all switch to OPM.
I remember a piece called SPAG (I think) that could turn FORTRAN spaghetti code (with lots of GOTOs) into relatively clean, structured code. It was very useful.
It's crazy to think that any programming language is that old.
As someone who has been programming for nearly 50 years of it, it seems less remarkable.
I don't see why. LISP is just a year younger and COBOL is 2 years younger. And Algol, spawned a year after FORTRAN, is no longer used as such (although there is now GCC support for Algol 68) but spawned many "Algol-like" languages, including most of the languages used today ... and even modern Fortran can be considered "Algol-like", having evolved to include its block structure.
FWIW, I started programming in 1965, in FORTRAN II.
Pascal and ADA are the direct successor of Algol 60(forgot the year of the first simpler dialect) and 68.
Algol, Pascal, Oberon, Simula, ADA, Julia (afik)
Modern Fortran is very different from early Fortran. If it wasn't for the name you wouldn't think they're the same language.
I learned Fortran 77 in 1988, oh weird memories
After learning Pascal I thought fortran was definitely strange and moved on, never to touch it again
I never learned Fortran and not gonna now, too.
It just seems so much work. Pascal was a breath of fresh air.
Google published a short video this week about how they used Gemini 4 Argon to migrate a Fortran code base to Rust: https://www.youtube.com/watch?v=biOWEPYyS5c
I learned to program Fortran at 13, 55 years ago, it was old then
still blows my mind that half the python data science stack is basically just a wrapper around 40 year old fortran code.
I've read that, but I tried to find some examples and couldn't.
I think the idea is that blas + lapack are still at the foundation of basically the whole stack. Back in the day (or at least when I last looked), numpy was very much built on of them, and the rest of the data science stack was built on top of numpy. No idea how much these things are still the case.
At this point it has been translated to C and now they patch the C directly but: https://github.com/numpy/numpy/tree/main/numpy/linalg/lapack...
I abandoned FORTRAN for good when I discovered C.
"A good FORTRAN programmer can write FORTRAN in any language"
It’s not Fortran style, but the code of the original Bourne shell is a remarkable piece. “How to write Algol in C”
"Real Programmers Don't Use PASCAL": https://homepages.inf.ed.ac.uk/rni/papers/realprg.html
We're all stuck writing COBOL now.
“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
I worked on BLAS. Amazing language and tremendous impact it's had over the decades.
Learn FORTRAN once, understand the C/C++/... linkage model forever.
The company I work for, has a subscription to O'Reilly. While searching for something "side", unrelated to day by day job, I ran across the beautiful book "Modern Fortran". The Fortran in the book (2008+ standard)is very different from the clumsy lectures of F77. It is a beautiful language. I'm sold.
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.
Thank you,Fortran!
Congrats! Here's to 70 more years!
FORTRAN 77 was the language for the first programming language course I took. I absolutely hated computers and programming after that course. Later I took CS courses and used Pascal -- one day the concept of abstraction hit me as we were developing data structs in the 2nd semester and the light went on. That is when I first started to love programming. FORTRAN was thereafter referred to as the F language. Sorry to be a bummer, but I still recoil when I hear about that language.
"I don’t know what the scientific language of the year 2050 will look like, but I know it will be called Fortran."
Horray! I'm partial, of course, to Fortran 77 and until very recently, still used it. Mostly taking consulting jobs moving it to Matlab or Numpy and verifying it.
My first language, I should try and mess with it again. It has been decades since I used it.
I believe it has changed quite a lot, keeping its focus for scientific/engineering computing, but adapting more modern language constructs. I'm not sure how much of the archaic stuff (COMMON blocks, ENTRY points etc) is supported in the more recent standards for backward compatibility.
Aren't COMMON's implemented as static structures? Stuff that's accessible from multiple functions - except that Fortran requires explicit rather than implicit reference.
It is way of sharing variable values without using parameters. But it is ugly and easy to make errors, e.g. accidentally missing a variable out of the middle of the list in one function or subroutine means all the later variables have unexpected values.
It is a log time since I did any FORTRAN. Maybe they improved it?
COMMON, ENTRY, and EQUIVALENCE are certainly frowned upon in modern Fortran style, as the language has gotten less error prone ways of accomplishing the problems those features ostensibly solved. But they still exist in the language for backwards compatibility.
Rust is the fortran of its age.
the real test will be on the longevity side.
Sadly no. BLAS/LAPACK are written in Fortran and they are the core of Numpy for Python and several other packages. Megafast number crunching it's mainly the #1 feature of Fortran. Just K can be on par and, well, it's propietary and even if it shines by itself doing calculations on vectors, integrating it with libre projects it's both impossible license wise and from a practical point, even if K was free.