The semantics of pointers in Fortran are much better, from the point of view of an optimizer writer, than the semantics of C pointers, optimizing which has been shown to be NP hard. So the fact that there's a feature of Fortran that is subtly different from C pointers and has even better semantics for optimization is an elephant. Every organization that has a style guide for Fortran programming, i.e., everybody who writes real programs, recommends to use "implicit none". Many processors have an option to assume it.

It would be a greater service to retire C++. Leslie Hatton (see http://www.cs.kent.ac.uk/people/staff/lh8/pubs.html, and do a Google search for more) has actually done some quantitive studies, and finds that on average a C++ program has 2 to 3 times the statically detectable defect density as an equivalent program in C, FORTRAN 77 or Ada, and the cost-to-repair per defect is also 2 to 3 times higher, resulting in an ownership cost for C++ programs that is roughly six times greater.

Here's an example. After teaching C++ numerous times, I was discussing a simple laboratory exercise that I gave the students: Construct a package to do complex arithmetic. I remarked that they repeatedly made the same mistake, even though I warned them of it explicitly several times: They returned a pointer or reference to a local struct or length-2 array. Of course, as soon as the function returned -- BANG -- the local variable was gone. My colleague got very quiet, and called me the next day to tell me that he had had a C program for about twelve years that occasionally got a bizarrely wrong answer. It turned out that one function was returning a pointer to a local variable. He didn't know precisely how many hundreds of hours he'd spent searching for that problem. This guy is no naive beginner. He wrote the powered-descent code for the Apollo Lunar Lander, tons of Shuttle code in Hal S, and was called out of retirement to write the powered-descent code for Mars Exploration Rover after the Mars Polar Lander crashed because its powered-descent code failed.

This problem isn't unique to complex arithmetic. Even sophisticated C and C++ programmers occasionally make this mistake in functions intended to return a composite result. Even if they do remember to malloc the result, the caller might forget to free it, resulting in a memory leak. Fortran functions can return composite results without resorting to pointers. There is therefore no temptation to return a pointer to a local variable, and no chance for a memory leak.

Here's another example. In early stages of the Cassini project (a spacecraft now on its way to Saturn), JPL was having trouble finding a "rad hard" processor. One day, the armed forces and CIA decided there was no really good reason to keep their rad hard processors under wraps, and suddenly we found dozens of really good ones. We looked at the specs and said "That one is perfect." So we froze the processor spec and started designing around it. When it came time to start the flight software, the developers found that the only available programming environment was Ada (why were they surprised?). They were hopping mad, because they had hoped to write the flight software in C++. Then, they noticed the COMPILER was finding bugs that they might NEVER have found if they had used C++. As with most religions, the most recently converted are the most zealous advocates. The same is true of these guys.

Here's another example. The Mars Pathfinder flight software *was* written in C and C++. The authors knew of a priority inversion involving interrupts from the modem, but chose to ignore it. Well, on Mars, the poor little machine rebooted hundreds of times every day because the priority inversion kept the processor from getting around to updating the heartbeat clock -- which was the interrupt frozen out by the inversion. Of course, if they hadn't sent any data back, there wouldn't have been any modem interrupts to cause the inversion w.r.t. the heartbeat clock, but.... Ignoring the priority inversion would have been impossible in Ada.

Here's another example. JPL management decided that maintenance costs for the six-million-line spacecraft navigation suite would be reduced if it were re-written in C++. In 1996, the estimated cost of the project was 120 work years. Since there were at the time seven work years per year being invested in maintaining the Fortran suite, the project would have broken even in 2023 if maintenance costs were reduced to zero. Now, after investing -- guess how many (hint: 120) -- work years, the estimated cost to complete the project is -- TA DA! -- 126 work years. One guy worked on the interface for the integrator for the initial-value problem for ordinary differential equations -- the bread and butter of celestial navigation -- for 18 months, and didn't even finish designing the interface! The plan now is to continue to use the Fortran 77 version, from which a C version is derived automagically. Don't say "Just use numerical recipes!" There is no other ODE integrator in the world, in any language, that is up to the standard of performance, features and accuracy necessary for this job.

Stephen Zeigler (see http://sunnyday.mit.edu/16.355/cada_art.html) has measured ownership costs for equivalent C and Ada programs, and found his C programs to cost twice as much as Ada programs. Fortran 95 programs are more reliable and less expensive to own than FORTRAN 77 programs, so the disparity between C++ and Fortran 95 programs is probably greater than the disparity between C++ and FORTRAN 77 programs.