In defense of FORTRAN
Firstly, one has to specify which FORTRAN. 77? 95? 2008? The language has evolved a great deal, possibly even more so than C++
Secondly, people who attack it fail to realize that even FORTRAN-77 had two huge advantages over its competitors.
One was for the scientist/programmer. The compiler could/can autogenerate code to check array subscripts at runtime. Given the declaration REAL A(100,200) then any reference A(I,J) is invalid if I<1 or I>100 or J<1 or J>200. With the compiler generating subscript checks, many bugs immediately crashed the program, rather than randomly corrupting random data elsewhere. C compilers couldn't do this.
Note also that (say) I=101 and J=1, or I=2000 and J=-1, are detected as programming errors even though in both cases the result of blind address arithmetic will be within A
And when the program was debugged and ready for use in anger, you recompiled with checks off and other optimisations on. Which meant that number-crunching code in FORTRAN could be faster than in C, the second huge advantage.
In particular, a FORTRAN compiler is permitted to assume that in a subroutine
SUBROUTINE FRED( A, B, M, N)
REAL A(M,N), B(M,N)
there is no memory overlap between the arrays A and B, which allows for many optimisations of statements like
A(I-1,J-1) = A(I-1,J-1) + B(I,J)
IN C-style languages A and B are pointers to chunks of memory, and the no-overlap assumption can't be used in nearly so many contexts.
Since F77, FORTRAN has advanced so that now many operations on arrays can (and should) be expressed as a single statement with no sequencing specified by the programmer. The compiler is free to perform whatever sequencing and parallelisation it thinks will work best. Your FORTRAN 2008 code is hardware architecture-independant. Your compiler generates a realisation that best exploits whatever it's running on, be that a pair of Intel Xeons with four cores apiece and a single RAM address space, a top-of-the-range or a cluster of a few such beasts, or tens or hundreds of them, that you wish to use in parallel.
Automatic parallelisation is a big and hot topic and probably still in its infancy. Recent FORTRAN languages have at least freed the compiler from arbitrary constraints accidentally imposed by a programmer who previously had to specify an arbitrary sequence and who couldn't indicate that he really didn't care about the ordering of this or these loops.
That said, I'd stil choose to write the outer parts of my programs in Python (using NumPy, SciPy, and suchlike) and call from there to number-crunching codes written by experts.