Fortran is an excellent choice for numerical computation. Its non-aliasing assumption allows for compiler optimizations that dramatically speed up computations. It is even easy to get started with concurrent code through OpenMP. When I need to run a simulation or a discontinuous optimization algorithm, I turn to Fortran first.

Here are some resources I have collected over the years.

"Introduction to Modern Fortran" (Fortran 2003): http://people.ds.cam.ac.uk/nmm1/Fortran/index.html

Fortran Wiki: http://fortranwiki.org/fortran/show/HomePage

List of Fortran tutorials: http://www.fortran.com/the-fortran-company-homepage/fortran-...

Fortran vs. C: http://www-cs-students.stanford.edu/~blynn/c/fortran.html

Fortran's influence on C's "restrict" keyword: http://www.drdobbs.com/the-new-c-it-all-began-with-fortran/1...

Fortran is still better at multidimensional arrays. Other than Matlab, few other languages do multidimensional arrays at all. C-derived languages use arrays of arrays, and use templates, macros, or objects for multidimensional arrays. Fortran optimizers have lots of multidimensional array-oriented optimizations which other compilers usually lack.

I tried to talk the Go and Rust people into putting in multidimensional arrays, but the discussion degenerated into bikeshedding, with arguments for fancy but slower representations so you could take arbitrary N-dimensional slices from a multidimensional array.

Guy Steele and his group had a really interesting thing going with the language Fortress (name is a nod to Fortran of course, but fortified). It was meant for high productivity as well as high speed (petaflops range). It got shelved after Oracle bought Sun. It was one of the three languages seeded by DARPA funding for high productivity computing

https://java.net/projects/projectfortress/pages/Home

https://blogs.oracle.com/projectfortress/entry/fortress_wrap...

It is simply due to apprenticeship. Physicists do research, and their code is research code. Like most other research, the research code is maintained and used in-house. As most in-house non-shared code (in any language), it is impenetrable unless you take apprenticeship. The masters are typically old and FORTRAN is their language and it is the only choice for the apprentices. Once the apprentices graduate and become masters themselves, they further developed their own in-house code and it is inevitably in FORTRAN too. As any over-developed code, it is too expensive to migrate even when the new master recognize the shortcoming. The bottom line, FORTRAN is not bad once you are familiar with (and invested in) it, so FORTRAN persists over another generation of apprentices ...

However, there is slight change. The new generation of masters often do know other languages, so they sometime tolerate their new apprentices to use other language and still able to teach them. So at this point, by far, not all physicists use FORTRAN.

FORTRAN will die out, just takes time.

One of the sticking point is the library BLAS/LAPACK. It is in FORTRAN. Or more precisely, its interface is in FORTRAN. I don't foresee this will change for a long time. So FORTRAN will be like COBOL, it will persist even when no-one really use it anymore.

> Interestingly, C/C++ beats Fortran on all but two of the benchmarks, although they are fairly close on most.

Unless I missed something, this directly contradicts the quotes benchmark source[1], where C beat Fortran on all tests except one (where they were tied), and usually by a wide margin. Plus I believe gcc usually produces slower code than Intel's compilers (at least for C), so it's not clear that C-gcc and Fortran-Intel is a fair comparison.

But beyond that, I'm always confused as to why there is a significant difference. I would expect two compiled languages with reasonable compilers to perform almost exactly the same when they're doing nothing but arithmetic operations, since those are almost entirely determined by the CPU, not the cleverness or speed of the standard library algorithms. Can anyone enlighten me?

[1] https://benchmarksgame.alioth.debian.org/u64q/fortran.html

1. A program from 30 years ago will compile and run.

2. As a research student your first program is likely to be a F77 program written by your professor or an older colleague.

3. A library from 30 years ago can be easily wrapped into a modern program, compiled and run.

4. Arrays are really the most important thing for this sort of programming and since F90 array level operations have been baked into the language.

5. It is fairly trivial to write fast Fortran.

6. Fortran is much easier to use for numerical stuff than c++

When I was doing my graduate studies in astrodynamics (spacecraft trajectory design) at Purdue University circa 2003, we worked closely with the Jet Propulsion Lab (JPL) and got to use a lot of their excellent astrodynamics code (used for missions like Galileo and Cassini). It was all Fortran.

I heard that there was an effort at JPL to convert over to using Python. I'm not sure how that went. Maybe they were just writing Python bindings for their Fortran code? I know that much of SciPy consists of Python bindings for Fortran and C code [1].

The software I used to do "nonlinear programming" (i.e. parameter optimization), called NPOPT, was also written in Fortran.

[1] https://www.scipy.org/scipylib/faq.html#how-can-scipy-be-fas...

"Early Fortran (designated in allcaps as FORTRAN)" that would be because it is an acronym "FORmula TRANslator".

Fortran continues to do that well. And as the article mentions scipy doesn't run as fast.

The logical successor to Fortran was APL (Arithmetic Programming Language) but its notation really killed it.

The properties that keep Fortran rolling (easy to start using, effective in translating formulas into computation) persist.

The author is I think being a bit unfair to C++ when it comes to matrix/array handling. Their example of things that would be difficult to do in C/C++:

A = B

A = 3.24 * B

C = A * B

B = exp(A)

norm = sqrt(sum(A * * 2))

Quoting:

"Similar C/C++ code simply does not exist ... Having to use libraries instead of intrinsic functions means the resulting code is never as neat, as transferable, or as easy to learn."

While this statement is true, I think strongly undersells how well these kinds of libraries can be "baked" into C++ through operator overloading, templating, etc. See for example, the Eigen library [http://eigen.tuxfamily.org/].

> If a function that takes a ‘real’ is fed a ‘const real’, it will return an error. It is easy to imagine how this can lead to problems with interoperability between codes.

What's he talking about? This is wrong!

One interesting fact that supports the point of the article is that Matlab is actually using the Fortran code for its implementation of special functions https://www.mathworks.com/matlabcentral/fileexchange/6218-co....

The amount of existing scientific code in Fortran is huge and there's a chicken and egg situation (new code uses/extends old code so new code will also be in Fortran) that will lead to further increasing it!

It's funny that someone has to write an article to defend modern FORTRAN to people who write in JavaScript, which is the best proof we programmers have of entropy.

Even if you are using python, R or java you are still best off linking to matrix subroutines in fortran if you want to solve or diagonalize, get eigenvalues and such. This is not just about raw performance but also correctness, ecology of roundoff errors, etc.

As a physicist please have faith in us. We don't all use Fortran. I use Ruby as much as possible and it's fun because it forces me to write libraries that mimic ones that are found in other languages. So I end up learning a lot.

When I was in undergrad I did some computer simulation work for my professor. He programmed in FORTRAN while I had been trained in C/C++. I did my simulations in C/C++ and I also wrote some libraries for his FORTRAN code so he could have more dynamic configuration files. At the time I thought that FORTRAN was an anachronism and was surprised that it was still being used in physics.

This was 1992.

What ever happened to the effort to bring Fortran to LLVM (from Los Alamos I think)?

I've been looking for a Matlab alternative and been disappointed with either the performance or the syntax of Octave, Python, and Julia. I'd known Fortran had modern features and updates every few years, but never tried to pick it up since the excitement seems to be elsewhere. This article is convincing that Fortran is worth trying out.

FORTRAN may be faster but one graph shows Python recently overtaking it in mentions of Astronomy papers [0].

[0] https://mobile.twitter.com/astrofrog/status/7870072618771660...

I have one issue with the article. The way to dynamically allocate a multidimensional array in C is the following:

  size_t m, n;
  ... set m and n ...
  int (*a)[m][n];
  a = (int(*)[m][n])malloc(sizeof(*a));

And you access it via

  (*a)[x][y]

  free(a);

  void do_with_array(void* raw_array, size_t m, size_t n) {
    int (*array)[m][n] = (int(*)[m][n])raw_array;
    ... do whatever ...
  }
  do_with_array(a);

My reason for using fortran (when I was studying physics) was that when going through the university library looking for a computational physics textbook, I couldn't find one that wasn't in fortran—actually I found one (computational physics, Giordano & Nakanishi) but it wasn't enough to get by. Fortunately I already knew fortran, because all the legacy textbooks+journals were written in the language.

Just in case you want to use fortran code in python here is the scipy HOWTO

Still up to date. https://docs.scipy.org/doc/numpy-1.10.0/user/c-info.python-a...

Interesting as I learned WATFIV on an IBM 370 with JCL/JECL under DOS/VSE.

There is an Openwatcom project that does C and Fortran but I think it is Fortran 77.

I had Fortran and COBOL on my resume but most jobs I took used Visual Basic.

some of the information here is a bit wrong. the idea that const is weaker than parameter is true, but not for the reasons given. any function taking a float, int etc. in C++ can also take a const float or const int.

its also unfair to suggest that C/C++ is as fault with not allowing a = b * c with array types. this is a failing of the standard library and easily fixed... operator overloading lets you create exactly this functionality, and std::valarray already does this for a lot of what you get in Fortran...

In our company we still us FORTH because the timing of each command is well known.

It seems like a number of R packages use Fortran. I'm on Mac and it needs to Fortran compiler to be installed so that at least some of the R packages can be compiled when doing updates.

> Note that Python, which is the darling of computer scientists

Actually physical scientists love Python as much as they love Fortran. It a lot of cases, it is the only two languages they know.