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++.
I used to work with a bunch of ex-Cray engineers back in the '90s. They'd rant and rave about how FORTRAN was faster than C due to eliminating one memory dereference on linear algebra operations (linear algebra being the reason to own a Cray).
I have a buddy at US Fish and Wildlife where they do river flow modeling with Fortran routines from the seventies formerly compiled on Windows machines. He was finding it increasingly difficult to get his all-powerful shadowy IT division to install a compliant MS Fortran compiler, and linux (somehow deemed governmentally untenable?) was out of the question. So i helped him get his ~2000 Fortran lines into C/C++. woowee... but did i see some hairy spaghetti code. A favorite maneuver was to jump out of a loop, change the loop counter on a subroutine branch, and jump back into the middle of the loop.
To elaborate: When people mention that supercomputing relies on Fortran code because it runs faster, that's primarily because the compiler knows the program can't modify a loop counter. So an optimizer can shovel off big arrays to array processors (1970s), GPUs (now), registers, etc, and do parallel or superscalar computation.
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.
It's been many years, but I seem to remember porting the NCAR Graphics Package written in FORTRAN IV to FORTRAN 77 on a Data General MV series box.
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.
This was from code originally from about 1978ish, which compiled on a Microsoft Fortran compiler from the 2000s. It looked something like (without indents):
DO I=1,10000
...
IF (QQQ .LT. RIX70) THEN
CALL IXNARF( I, J, R1, R7, XL23 )
GOTO 23
...
END IF
111 CONTINUE
...
END
IXNARF could change 'I' (because Fortran 77 passed arguments by reference not value) and sometime after line (er... "card") 23 it might jump back into the loop at 111.
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:
> Change the loop counter? That's supposed to be impossible in Fortran, isn't it?
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
3
There is no "standard" compiler. There is a Fortran standard, and there are standard-conforming compilers and standard-conforming programs.
There 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.
there is one in ocean sciences. I don't remember which one although if you are really interested I can find out. Somebody translated it into C as part of their phd.
All fluid modeling at least. I once worked for a company that built heat exchanger simulations. I spent limited time in Fortran but was able to successfully integrate some C++ and C# libraries. The language isn't bad at all.
I can certainly verify this. Look no further than Nastran [1] which is ubiquitous in the aeronautical / aerospace industry. Using fixed width fields isn't even uncommon--column edit and a few clever regular expressions go a LONG way. Even newer software [2] follows this paradigm, and I think with good reason. Mechanical engineers, as they insist on frequently reminding me, are NOT computer scientists. Nastran bulk data operates like a very tangible, physical-ish relational database free from some of the more advanced abstractions of more modern languages.
It's only unparalleled if you've never heard of the C99 'restrict' keyword. The major reason is like every other legacy system still in wide use, inertia. LAPACK alone will guarantee Fortan's life for decades to come.
If only every compiler vendor supported C99 (coughMicrosoft), perhaps C99 would be a usable alternative.
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.
More importantly, if your simulation software is made by a computer engineer without the direction of a scientist you might just end up with a really slow and biased random number generator.
I've said it before - leveraging "restrict" is far from trivial.
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.
Another major advantage over C and C++ is a language level support for multidimensional arrays, i.e. you don't have to reasearch available libs, depend on them, convert between them, etc. I fully understand resistance of scientific community to trying alternatives like C++.
L-BFGS-B is a hugely popular algorithm for box-constrained minimisation and the best implementation is still in Fortran. This is commonly used in machine learning. Things like scipy.optimize.fmin_l_bfgs_b are just wrappers for the Fortran code.
