Fortran is actually still in major widespread use, particularly in the scientific and engineering fields. This is partly because it has unparalleled speed in some domains, better even than C or C++.
DO I=1,10000
...
IF (QQQ .LT. RIX70) THEN
CALL IXNARF( I, J, R1, R7, XL23 )
GOTO 23
...
END IF
111 CONTINUE
...
END
oh and there was like three comments in the whole several thousand lines, including my favorite at the top of one of the main loops:
C CHUGGA CHUGGA CHUGGAThen there was the proposal for a Fortran COME FROM statement.
I laughed way harder at this that it warranted.
It is impossible inside the loop, even in F77.
But if a global variable is used as a loop counter, and the variable is altered in a subroutine, then the code altering the variable is not inside the loop. At least not in the eyes of the Fortran compiler.
$ cat test.f08
program test
integer i
do i = 1,3
call sub
print *,i
end do
contains
subroutine sub
i = 3
end subroutine sub
end program test
$ gfortran --std=f2008 test.f08
$ ./a.out
3There are popular compilers, like gfortran and the Intel compiler.
My point had nothing to do with popularity. My point is that non-standard-conforming programs can have anything happen when they execute, including starting World War III (see https://www.google.com/search?q=fortran+"start+world+war"), and showing output from one compiler doesn't prove anything.
Not so long ago, supercomputers typically had Portland Group, Cray and Pathscale compilers installed. Nowadays it's pretty much Intel and gfortran.
The FOR loop become a hint that tells the compiler it can take extraordinary measures on the nested instructions.
You could do the same thing in C if you use compiler directives, or in other languages like Pascal, but there's a critical mass of Fortran code, so that's where vendors put the effort.
If memory serves, they had a trick to create simulated pointers, by declaring a one element array somewhere in memory, and then indexing way outside of its bounds in order to point into other areas of memory.
I don't remember the details, but I seem to remember there was a statement ("EQUIVALENCE"?) that facilitated this magic.
1. https://en.wikipedia.org/wiki/Nastran#Software_architecture 2. http://www.zonatech.com/ZAERO.htm
In practice, what you do is look at the assembly of your inner loops, scratch your head, and try putting "restrict" in various places that seem like they'd make sense, and then look at the assembly of your inner loop. Which requires building a mental model of what the assembly of your inner loops ought to look like, and then actually looking at it, and then running it to see if your idea of what the assembly out to look like was actually a good one.
If your expertise is in numerical methods first and assembly-level optimization second (or, like, nth), Fortran can save you a lot of ballache.
And, inertia isn't the only reason for Fortran remaining popular. Put simply: if you tell a mech.eng./physicist/whatever to write code in Fortran, whatever is produced will likely be fast and relatively readable. Do the same with C/C++, and it will be significantly slower and a horrible mess. Templates-all-the-way-down type of stuff.
Sure, a software engineer could write a C/C++ version that was elegant and as fast/faster than the Fortran code. But scientists don't have the money to hire software engineers. You're lucky if these projects are even under version control.