For numerical code Fortran is definitely
better than any alternatives, without doubts. The code itself would be
simpler(clearer) so your performance as programmer would be higher with
less bugs.

How can you claim this?
I just see too many contradictions to such a claim:

1. For "numerical code" the difference between C and Fortran is only
minor. (In fact C borrowed a lot of its formula syntax from just
Fortran...) That favors neither of the two significantly.

2. Whether or not the code is simple or clear depends partly on how
familiar the reader is with the syntax/language at hand, partly on the
skills of the code's author. It is possible to write virtually
unreadable code in both languages. Traditional Fortran code using only
capitals can be argued to be less readable, but that argument isn't
relevant these days when modern compilers accept lower case just the
same. So no specific advantage to any party here either.

The distinction between local variables and arguements in C that is
evident by the need to know which are pointers or not is not conducive
to readability. The peppering of code with the dereferncing '*"s is
not a good thing. Fortran got it better with pointer operations
requiring their own operators. Fortran pointers have a much richer
sematics so comparisons with C pointers are dificult for other reasons.

3. When judging the degree of freedom the author has for producing code
with good readability, Fortran has the disadvantage of rigid and
odd/archaic line formatting rules (in fixed format), and imposes limits
on line lengths (72 or 132), both of which enforce limitations in the
freedom the author has to arrange his/her formulas with a readable
layout in mind. (66 character positions to play with is really not
much!) C does not have this limitation, but on the other hand too long
lines don't behave very well when printed for instance. I.e., I'd say
this isn't so much a relevant issue to favor one over the other in
practical life.

Fixed format went out with all caps. But then how much 40 year legacy
code still works in C?

4. In Fortran it's often necessary to use more temporary variables to
store intermediate sub-expressions, or even literal numeric values (ever
used IONE or IZERO anyone?). This generally requires more lines of code
for expressing the same calculation in Fortran than in C. On the other
hand Fortran offers some convenient shorthands for implicit looping
(implied DO and index ranges, for instance) that need to be written more
explicitly in C (principle: "what you see is all you get", so "you have
to code everything you want to do"). So I find it hard to conclude one
way or the other which is "best" here, and it can also be a matter of
personal preference.

Most folks consider the ability to grab the internals out of C expressions
with embedded assignments as a prime example of a write only language
for hackers. The collection of += type symbols have no equivalent in
conventional mathematical notation so need explanation as to their
semantics, particularly with && and such. Programming is an area where
clever is often a rather bad thing and you seem to be like a lot of
features that encourage cleverness at its worst.

5. Regarding this:

And all that without any performance penalty on run time
(execution).

That is in fact not always the truth. In both of these languages it is
an important principle that "you don't pay for what you don't use", but
in real life things aren't always that ideal. Since the claim quoted
above was about numerical code, I think the common feature of run-time
checking of array indices[1] can serve as a good example. You don't pay
this price in C, but then again you are allowed to shoot yourself in the
foot if you like, and bugs in the code causing for instance indexing
errors unfortunately tend to magically intrude into code of either
language. Stricter rules regarding aliasing can give a Fortran optimizer
an advantage with arrays for instance, but there might also be an
advantage in the almost complete freedom (flexibility) given to the C
programmer dealing in the pointer/array minefield.

Subscript checking is a common runtime option in Fortran. Less commonly
supported in C where it is more needed because of the C storeage allocation
idioms. Once past debugging the option is turned off. During debugging
is is a great help. The default is option off. It is clear that more
folks should use it judging from the questions that keep coming up.
Curious feature of C that it allows more, better and bigger errors!
Most would view that as hardly a worthwhile feature.

And I can probably make a long list of such arguments, but I think I'll
stop here ... An assumption is of course that we either compare a good
Fortran programmer with a good C programmer, or a bad with a bad one.
One writes best code in a language that one is familiar with, and
comparing Fortran code from a good Fortran coder with C code from a bad
C coder just isn't relevant IMHO. Or vice versa.

Bottom line: When programming/coding, one really has to know one's
programming language no matter which one is chosen. Regarding the
readability (or immediate understanding) of the finished code for other
people not familiar with the language, see my points 1 and 2 above.

So, if you know Fortran but not C, your best off if you do your work in
Fortran. If you know C but not Fortran, then choose C. If you know both
very well, you're either lucky in the case you're starting something new
and can choose which one best fits the problem. Or, you're unlucky if
you're assigned the task of maintaining some other fellow's code.

[1] Yes, I know one often can turn this off with many compilers, but in
real life one doesn't always dare that.

Are you seriously suggesting that running with wild subscripts is a thing
to be tolerated in a "working" program?

Relevant Pages

Re: Can Fortran ever become logically complete?... describe circumstances around the way standards were historically changed ... But, regardless, my take on Fortran language development is the complete ... Hasn't Fortran always focused on coding familar but abstract concepts in a natural way, always aiming at the best possible performance, but never forcing the programmer to think in terms of implementation/hardware concepts where it can be avoided? ...(comp.lang.fortran)

Re: allocatable array *not* equivalent to dynamic allocation?... It mostly adds to Fortran allocatables a capability that pointers... But C pointers are used for more, including what ALLOCATABLE would be used for in Fortran.... C is a fairly simple language, which was nice when it was new, as it made it easier to write compilers for small machines. ... Then assembly, then FORTRAN 77, then Basic, then a data general macro language that I've also forgotten, then 360 assembler, then Cyber 171 JCL, then Exec/Exec2, then Rexx, then C, then PL/1, then f90, then Perl, then HTML from Script/GML), PHP, and JS. ...(comp.lang.fortran)

Re: Fortran vs C++ for scientific computing... better than many who do have it as a native language.... it's built into the languange using additional, convenient syntax.... It almost sounds to me as though you are saying that Fortran... adds stuff by writing libraries just as a C programmer does. ...(comp.lang.fortran)