Originally known as FORTRAN, but written in lower case since the 1990s with Fortran 90, this language was developed initially by John Backus as a way to make writing programs for the IBM 704 mainframe easier. The 704 was a 1954 mainframe with the honor of being the first mass-produced computer that supported hardware-based floating point calculations. This functionality opened it up to a whole new dimension of scientific computing, with use by Bell Labs, US national laboratories, NACA (later NASA), and many universities.
Much of this work involved turning equations for fluid dynamics and similar into programs that could be run on mainframes like the 704. This translating of formulas used to be done tediously in assembly languages before Backus’ Formula Translator (FORTRAN) was introduced to remove most of this tedium. With it, engineers and physicists could focus on doing their work and generating results rather than deal with the minutiae of assembly code. Decades later, this is still what Fortran is used for today, as a domain-specific language (DSL) for scientific computing and related fields.
In this introduction to Fortran 90 and its later updates we will be looking at what exactly it is that makes Fortran still such a good choice today, as well as how to get started with it.
Modern Fortran
The release of the Fortran 90 (F90) specification in 1991 was the first major update to the language since Fortran 77, and introduced many usability improvements, as well as the dropping of punch card era legacy requirements and limitations to variable lengths and more. This is the reason for our focus on F90 here, as there is no real reason to use F77 or earlier, unless you’re maintaining a legacy codebase, or you have a stack of new cards that need punching. In case you are dying to know what changed, the Wikibooks Fortran Examples article has examples of early FORTRAN all the way to modern Fortran.
Of note here is that a modern Fortran compiler like GCC’s GFortran (forked from g95) still supports F77, but users are highly encouraged to move on to Fortran 95, a minor update to F90, with GFortran supporting up to F2008, with coarray support, as covered later. F2018 support is still a work in progress as of writing, but many features are already available.
Support for the latest standard (F2023) is not widely available yet outside of commercial compilers, but as a minor extension of F2018 it should eventually get rolled into those features as the implementation progresses. This means that for now F2008 is the latest standard we can reliably target across toolchains with new Fortran code.
Beyond GFortran there are a few more options, including Flang in LLVM and LFortran in addition to a gaggle of commercial offerings. Unless you intend to run high-performance computing code on massive parallel clusters like supercomputers, the GNU and LLVM offerings will probably suffice. Simply fetch either GFortran or Flang from your local package manager or equivalent and you should be ready to start with programming in Fortran.
Hello World
As with most DSLs, there is very little preamble to start writing the business logic. The ‘Hello World’ example is most succinct:
program helloworld
print *, "Hello, World!"
end program helloworld
The program name is specified right after the opening program keyword, which is repeated after the closing end program. This is similar to languages like Ada and Pascal. The program name does not have to match the name of the file. Although there’s no explicit specification for what the file extension has to be for a Fortran source file, convention dictates that for F77 and older you use .f or .for, while F90 and newer uses generally .f90 as extension. Although some opt to use extensions like .f95 and .f03, this is rather confusing, isn’t recognized by all compilers and all of those are similar free-form Fortran source files anyway.
Tl;dr: Use .f90 for modern Fortran source files. Our Hello World example goes into a file called hello_world.f90.
The other point of note in this basic example is the print command, which looks somewhat cryptic but is quite easy. The first argument is the format, reminiscent of C’s printf. The asterisk here simply means that we use the default format for the provided value, but we could for example print the first string as an 11 character wide field and a variable string as 8 wide:
character(len=8) :: name = 'Karl' print '(a11,a8)', 'My name is ', name
This also shows how to declare and define a variable in Fortran. Note that if you do not start the code with implicit none, variable names that start with I through N are considered to be integer type and real otherwise. With gfortran you can also globally do this by compiling with the -fimplicit-none flag.
A total of five basic types are supported:
- real
- integer
- logical (boolean)
- complex
- character
Finally, comments in Fortran are preceded by an exclamation mark !. It’s also relevant to note that Fortran – like all good programming languages – is case insensitive, so you can still write your Fortran code like it’s F77 or Fortran II, yelling in all caps without anyone but the people reading your code batting an eye.
Hello Science
Now that we have got a handle on the basics of Fortran, we can look at some fun stuff that Fortran makes really easy. Perhaps unsurprisingly, as a DSL that targets scientific computing, much of this fun stuff focuses around making such types of computing as easy as possible. Much of this can be found in the intrinsic procedures of Fortran, which make working with real, integer and complex values quite straightforward.
For example, conjugating a complex number with conjg:
Basically, whatever mathematical operation you wish to perform, Fortran should have you covered, allowing you to translate your formulas into a functional program without having to bother with any dependencies or the like. This includes working with matrices and getting into the weeds with numerical precision.
Even better is that you’re not stuck running your code on a single CPU core either. Since Fortran 2008, Coarray Fortran (CAF) is now part of the specification. This feature enables parallel processing, which is generally implementing on top of the Message Passing Interface (MPI) protocol, with gfortran implementing CAF support. Depending on the selected option with the -fcoarray= flag, gfortran can use the ‘single’ image (thread) option, or with a library like OpenCoarrays it can use MPI, GASNet, and others.
When using CAF with MPI, the program (‘image’) is distributed across all nodes in the MPI cluster per its configuration, with synchronization occurring as defined by the program. With OpenCoarrays available from many local OS repositories, this means that any budding molecular scientist and astrophysicists can set up their own MPI cluster and start running simulations with relatively very little effort.
The DSL Life
Much like when we looked at COBOL, a DSL like Fortran is often misunderstood as ‘yet another programming language’, much like how in the 1980s some thought that the scientific and engineering communities were going to switch over to Pascal or Modula-2. One simple reason that didn’t happen lies in the very nature of DSLs, with them being developed explicitly to deal with that specific domain. It will always be possible to do everything a DSL does in any generic programming language, it’s just that a DSL can be optimized more exactly, and is often easier to maintain, since it is not generic.
There are many things that Fortran does not have to concern itself with, yet which haunt languages like C and its kin. Meanwhile, reimplementing Fortran in C would come at considerable cost, run into certain limitations of the language and potentially require compromises in order to get close to the original functionality of the DSL.
Running a cluster with Coarray-based Fortran source, churning through complex simulations that require utmost control over precision and where one small flaw can waste days of very expensive calculations, those are the kind of scenarios where you’re not looking for some generic language to poorly reinvent the wheel, but where you keep using the same – yet much more refined – wheel that has gotten us this far.
Fortran makes me facepalm. It’s as verbose as Python, yet with all the issues that are also present in C++.
If you need to do university-level math then MATLAB can be 🏴☠️downloaded🏴☠️ for free from the 🕸 and it also has Simulink. If you need direct-to-machine code then it’s easier to just use C++. For graphical stuff nowdays there’s choice: UE5, Unity etc.
With the difference that Matlab is interpreted and very slow compared to compiled Fortran. Matlab is good to proof the math but the heavy lifting should be definitely done by Fortran. With ATLAS instead of BLAS. It becomes up to 100x faster than Matlab. Had to do all that in grad school. Oh, and nothing wrong with verbose, can read a code from 1970 easy enough.
However, a Real Programmer can do anything in FORTRAN.
You want verbose, you hire a COBOL weenie.
in the late 1960s one could learn from Daniel McCracken’s A Guide to Fortran IV Programming.
And there were subtle distinctions from Fortran II, which was on the old IBM 7000 series mainframes.
FORTRAN, used in EE university for a few courses – actually had a few advantages over the usual languages.
For highly controlled print formats, doing numerical analysis, massive equations – it’s great for that.
But I always blew the stack, one mistake with a missing/extra parameter and it craters. It does crash hard.
I have no desire to go back to fortran again. Fortran IV was my first actual language (360 assembly, and a couple others, came first) and I still get the occasional shakes thinking about tracking down bugs in complicated code. Then repunching the card or cards. (Who forgot to turn on the automatic serializer on the cardpunch, then dropped a deck? fun times)
Ratfor was a hella improvement, in the sense that it reduced the hardcore spaghetti factor, but I still chose Pascal or Lisp when I could, for the easier debugging, if that says anything about how much I do not miss it..
i am surprised that my disagreement isn’t a nitpick but rather the article’s repeated explicit main thrust!
i do not think fortran is a DSL. it is YAPL.
the thing about fortran is that it’s sseminal for so many things that we take for granted in every programming language today. it didn’t elide subroutine calls because scientists don’t need them. it lacked them because it was approximately the first “third generation programming language”! fortran wasn’t against function calls…rather the opposite. its most impressive result is showing that these problems are not only solvable but actually easy to solve. it inspired everyone that came after it to think of the incredible feats of mechanical language translation that are possible.
Backus himself is quite explicit about it being Yet Another Programming Language in a 1978 retrospective on fortran. in as many words he says that the deign goal of the language was simply to have something that could justify the creation of a compiler. even in 1978, he knew he had to beg the audience to put themselves in the mindset of 1954 so that they could understand how incredibly primitive fortran’s innovations were https://dl.acm.org/doi/abs/10.1145/960118.808380
and Backus himself became fond of functional style, once he had seen a couple decades of progress built on top of fortran’s core innovations. it’s clear that he views the 1950s as “trapped in the Von Neumann style” https://dl.acm.org/doi/10.1145/359576.359579
fortran the language is just a footnote to the invention of the concept of a compiler for a high level language. the expression syntax wasn’t designed around the needs of scientists so much as it was designed around the theory that something new could exist in the world: an expression parser.
anyways in real life fortran’s limitations are all pain for actual scientists. 25 years ago i had a summer job porting a large fortran nightmare from VMS to Linux using the awful Absoft fortran compiler. unfortunately i didn’t have access to actual users of the program so i found that 99.99% of the code was ‘unscientific’ and specifically unsuited to fortran. it was all UI and I/O. the actual math turned out to be just a histogram!!!! in real life, scientific programmers are often buried under mountains of poorly-factored code to implement very clunky UIs on top of I/O hardware that doesn’t exist anymore. and fortran was just about the worst language for all of the above.
fortran itself belongs in the dustbin of history. it’s much worse for every problem domain than languages that came decades later. it is decidedly not like cobol or ada that are still valued within their domains.
but the accomplishment that it represents is the foundation of everything that came after. it is the first yet another programming language.
anyways i’m writing partly because i’m frustrated with the misrepresentations in the hackaday article. but i also hope some readers see the living history represented by these articles that Backus published which we can still read today. if anyone’s reading the articles i’m linking to, i hope they also glance at Guy Steele’s impassioned defense of function calls. if Bjarne Stroustrup had taken this seriously instead of delivering a meditation on the importance of inlining to mitigate the mythical expensive procedure call, we wouldn’t have to suffer C++ today. https://dl.acm.org/doi/10.1145/800179.810196
Where are the FORMAT statements?
I kinda learned FORTRAN after I already knew BASIC and it felt like a practical joke. With Basic on a microcomputer, like the Commodore PET at school or the Altair in my bedroom, you wrote and debugged a program interactively – and given my skills at the time, more time was spent debugging than writing.
With Fortran, you wrote your program on paper, punched the cards and then mailed (US Postal service) the cards to the computer and they mailed the results back. I never got anything to actually compile and run.
“learned FORTRAN after I already knew BASIC”, “With Basic on a microcomputer, like the Commodore PET at school or the Altair in my bedroom, you wrote and debugged a program interactively”
My Uni had an IBM S/370 Model 165-II, 8 MiB core memory in 1976 when I learned FORTRAN. The non-networked system cost in excess of $400K. Undergrads were only allowed to use punch cards; TSO terminals were assigned to some seniors and grad students.
BASIC on a $1K microcomputer was a joy in the late ’70’s.
ITERATIVE programming on a mini-mainframe was simply not allowed for beginners.
I remember receiving my JCL card with only 5 seconds of CPU time allowed per batch run. I would have sacrificed my M-I-L for Coarray Fortran back on my first massive FORTRAN project in the 1980s. Then came Delphi.
“The program name is specified right after the opening program keyword, which is repeated after the closing end program.” This is unclear. Which is repeated after the closing end program? the opening program keyword or the program name? Taken as read it’s the keyword.
“The program name which is repeated after the closing end program is specified right after the opening program keyword.” Per the writer’s example. Still needs editing, should be two sentences.
Calling all caps “yelling” is a tactic adopted by the early internet bullies (who often go by the name “mods”) and should be eschewed.
It is easier to read ‘mixed’ caps dialog between people. However, early on, every program (Basic is what I remember) was written in ‘upper case’.
I agree, notice I don’t use all caps but the bullies/mods always need a knuckle rapping.
Anyone else remember the “FORTRAN Coloring Book”?
I don’t … but here is a link to the book.
https://archive.org/details/9780262610261
Hmmm, Above url only gets you a couple of pages…
The following seems to have all the pages availabe.
https://archive.org/details/FortColBkKaufman/page/n39/mode/2up
Oh my gosh, yes! I took Dr. Kaufman’s FORTRAN course at MIT. We were given a mimeographed copy of the book, which was still a work in progress in 1976. I already knew FORTRAN from my summer job, so I didn’t use the book very much. But I still remember one gag: “The * is also known as the Nathan Hale operator, because he had but one asterisk for his country.”
When I was in college, meteorology students were required to take a F77 course. The highlight of the course was creating a line editor (much like DOS’s EDLIN program). It was interesting for me because my dorm wasn’t equipped with many VT100 terminals, so I had to make due with the teletype that was repurposed as a printer.
Fast forward 4 years when the same students had to write numerical weather prediction programs. My classmates by that time were, like, “Time to put that F77 class to use so we can run our predictions on the campus mainframe.” I, on the other hand, had gotten ahold of a government surplus 8086-turbo and a copy of QBASIC. The program ran slowly (especially at double-precision), but at least I didn’t have to put in multiple weeks of debugging and finding every unwanted space and misplaced parenthesis like my classmates did.
When I entered college, the punch cards were on the way out. The seniors were the last to punch cards and wait for output from the data center. Missed that era by ‘that’ much! :D Yesss. Still most engineers (and of course all us CS majors) had to take Fortran. Also had a ‘programming landscape’ class to cover a lot of languages like Cobol, lisp, etc.) Pascal was the learning language of the times for CS. When I got a DEC Rainbow, I also was able to buy Turbo Pascal (1.0?) to write my ‘homework’ locally. Also bought Nevada Fortran as well at the time. Then upload to VAX and re-compile there. Saved a ‘lot’ of debugging time and phone time, or have to go to the lab and wait for a terminal. Fortran came in handy later as I helped maintain plasma boundary software (vehicle re-entry from space problems) for the scientists on the side of my main job. Nothing wrong with Fortran. It did and does the job then and now. I don’t dabble with it much anymore. I did buy an ‘up to date’ book on ‘modern’ Fortran to keep me up to date!
Interesting. I’ll probably get into Fortran at some point (likely after Ada). Right now I’m having to get used to using Python, as all the lab and engineering jobs in this part of the country primarily use Python and occasionally use Matlab for their simulations (at least the ones that mention it in the job listings).
Good writeup. My experience has been that people can write bad code in a great many different languages.
And good code too, for that matter.
But I still haven’t forgiven the computer scientists for telling me I had to switch to Algol. Wasted a lot of time on that one.
Wow,
Blast from the past.
My Masters Thesis (of 1983) was an adaptation of Green’s Theorem as a general purpose analysis package.
Unlike FEM, in with the entire volume must be discretized, Greene’s Theorem only requires the surface of the body to be discretized. Unfortunately, it’s also singular at the point of application and requires a lot of hand waving not to crash the system.
It was all written in Fortran 77. Luckily my school allowed graduate students to use dumb terminals unlike under grads who still had to punch cards. I had the mini mag tape with my dissertation on it until not too long ago.
At the end of the day, my thesis concluded that it’s basically a technique that’s not really suitable for numerical analysis. My professor was not particularly happy about the outcome, but I got my degree.
Fun times
When I started college in 1972, It was Teletypes and punch cards. So, I got myself a Teletype (thanks, unknown tech at the Teletype facility in Framingham, MA!) and, quite coincidentally, a job as a Teletype repair person at the Computing Center (they were obviously desperate, and I was a quick learner). So, I had an employee account on the mainframe (unlimited time, no charge) which was a CDC 3600/3800, soon to be upgraded to a CDC CYBER74. I managed to avoid punched cards altogether, though there were plenty who didn’t all through my time at UMass/Amherst. Still have a Computing Center logo’d card above my PC :-)
All my undergrad classwork was done on my Teletype (I bought an Omitec 701B acoustic coupler for $350) from my dorm room. Later, I managed to assemble a DEC VT-05 from scrap parts and moved up to 300 baud! I would have absolutely KILLED for a spreadsheet and a word processor. My only experience during school with a micro was a SWTPC 6800 system that I built memory boards for one summer. FORTRAN? I tested out of it as a freshman, and most of our coursework was done in Pascal (which I have never used again). Obviously, the 6800 system was assembly language, and I also picked up PDP-11 assembler and COMPASS assembler for the CDC CYBER.
When I started work at Data General in 1978, my first project was the D200 terminal, built around the Motorola 6802, so I was quite comfortable writing the keyboard scanning firmware in 6800 assembler.
And it was all downhill from there :-)
There is visual Fortran, if that helps… here in Intel’s quick start guide.
https://www.danysoft.com/estaticos/free/IntelVFwinprimpasos.pdf
IMHO, “running assembler/machine code using commands” is what Python is all about, too. I don’t suppose the two have much in common, but the idea is nearly the same.
Having said that, Python is really ANSI C in its core, so, technically, it is ANSI C with the extra-friendly layer on the top of. I imagine there are Python libraries out there that out-C any well-written ANSI C due to being machine-code at its core. I think there used to be some kind of assembler-compiler Python library, too, forgot the name.
Translation – some of that machine-code FORTRAN may have already been embedded in other places.