Why physicists still use Fortran (2015)

GP is saying the contrapositive for Fortran: you can have runtime bounds checks during development instead of disabling them for production builds.

I'm not sure which feature you're referring to, because while GCC has -fbounds-check, that's for the GNU Compiler Collection and only for frontends that support it (to wit, Fortran and Java). I don't know of any runtime bounds checking that ever made it into vanilla. Clang and GCC both have some limited array bounds checking, but it's static, and there are plenty of issues it won't catch. People maintained third party patches for a long time, but these are obsolete now. Perhaps you're thinking of ASAN/-fstack-protector-*?

"Professors usually have this legacy code on hand (often code they wrote themselves decades ago) and pass this code on to their students. This saves their students time, and also takes uncertainty out of the debugging process."

This is so true. I'm a PhD student in physics using Fortran for pretty much that reason. At the start of my PhD, in response to my supervisor telling me I should learn Fortran to modify our current codebase, I asked if I could rewrite what I'd be working on into C++ first, since I was already familiar with it and wanted to bring future development into a more "modern" language.

His response was "You could do that and it would probably be enough to earn your PhD, since it'll take you at least three years. But I suspect you'll want to work on something else during that time".

He was right. I later learnt one of our "rival groups" attempted the same thing and it took three phd students working full time for a year to rewrite their code from fortran to C++.

Yep. Most of my programming classes were either in pascal or c when I was in undergrad, but in my physics courses, all the way through my graduate education, I used FORTRAN. It's because physics doesn't change that much over the years, FORTRAN code that is time-tested and that works exists and there's no need to re-invent the wheel in another language when more interesting and important problems exist to solve.

A lot of the arguments in this post can simply be rebutted with basic abstractions. Things like "Dynamically allocating and deallocating ... 2D array" is easy in C++. You could easily have someone define a MathArray class and turn this messy fortran code:

    real, dimension(:,:), allocatable :: name_of_array
    allocate(name_of_array(xdim, ydim))

Into something that looks like

    auto *my_matrix = new MathArray();

The code the author showed demonstrates a lack of understanding of C and C++. Even if you restrict it to C your matrix code should look something like this

    typedef struct {
        size_t rows, cols;
        void values[];
    } mat;

    inline mat *matrix_make(size_t rows, size_t cols, size_t value_size) {
        mat *m = malloc(sizeof(size_t) + sizeof(size_t) + (rows * cols * value_size));
        m->rows = rows;
        m->cols  = cols;
        memset(m->values , 0, rows * cols * value_size);
        return m;
    }

While that code may be complicated the physicists only need to see....

    mat *matrix = matrix_make(10, 10, sizeof(double));

And if you'd really like you can hide the sizeof via a macro...

    #define MATRIX_MAKE(r, c, type) matrix_make(r, c, sizeof(type))

For me "real, dimension(:,:), allocatable :: " is much more complicated than "matrix_make"

Many of the issues people see in the speed difference between Fortran and C code will likely be based on their misunderstanding of how Fortran actually does their data layout and a misunderstanding of how the computer hardware (and what you're describing to C) to do. This "Double array" that was defined would never be allowed in production code. The amount you'd be hitting the OS for even small allocations is crazy.

The arguments for Fortran, as far as I'm concerned, are:

   1. We already know it
   2. We're not going to get grant money to rewrite a library
   3. We've built a bunch of computer clusters and have to justify what we spent (rather than buying 2 GPUs for your workstation)
   4. We've all spent a lot of time learning how to use MPI that we're never getting back.

Just a grad student, soon to be postdoc, so not a big wig on ECP.