>Why would IO be slow in any language?

I believe many Fortran implementations default to unbuffered io.

Which is probably easy enough to change.

But I think that's really the core issue. Physicists don't want to learn more about programming languages. They want whatever mostly works out of the box and has local documentation and expertise specific to their problem domain.

>Aren't arrays implicitly passed by reference in C also?

He covers that. C passes arrays by reference, but the individual elements aren't contiguous. He says Fortran passes an optimized reference.

Unless you're passing arrays of pointers to things about, the individual elements in a C array should be contiguous.

>Unless you're passing arrays of pointers

That seems to be the context from his example:

  for(i = 0; i < nrows; i++){
     array[i] = malloc(ncolumns * sizeof(double));
  }

I suppose the counterpoint is that he's doing it wrong. But again, maybe physicists just don't want a tool with that much flexibility.

I was taught to do it like this in C:

  double *a = malloc(sizeof(double)*nx*ny*nz);
  int id;
  for(int k = 0; k < nz; k++) {
      for(int j = 0; j < ny; j++) {
          for(int i = 0; < i < nx; i++) {
              id = k*nx*ny + j*nx + i;
              a[id] = /* some mathematical operation */
          }
      }
  }

You can do it in other ways (arrays of pointes, etc), but I think this is probably the simplest conceptually, and the memory is contiguous.

he's definitely doing it wrong there. As a scientific C programmer, I would never do that, I would malloc one contiguous array of nrows*ncolumns. And my freeing of the array would be as simple as his Fortran deallocate.

Sure, C could make multi-dimensional array handling nicer, but I have macros that basically do his A[x,y,z] for me, admittedly a bit more verbosely.

Many of his points about Fortran are true, but almost all his statements about C are false. Or nearly so, yes, copying an array of floats requires calling a function, memcpy, and not just using an equals sign, but that ain't rough and falls into his idea of "what actually happens ‘under the hood’ inside a computer". And others are easily handled by adopting things like the MKL (want to take the sin of everything in an array, see https://software.intel.com/en-us/mkl-developer-reference-c-t... )

Fair enough then, I suppose that in C you have to do something like that if you want both that your matrix size is decidable at runtime, and to be able to index it with m[x][y] rather than some function.

That’s not strictly true. You can malloc an m*n sized array and then assign to another array the pointer to the head of each column, allowing you standard style indexing.

If you do that, every access will actually dereference that pointer and won't be able to optimize the standard style indexing to a multiplication and addition, so this still carries a significant performance cost.

You can always use a macro (or inline function, if the array is a rich wrapper type):

  arr(m, x, y)

Not quite as nice, but not too bad.