Re: Ada vs Fortran for scientific applications

[Dick Hendrickson <dick.hendrickson@att.net>]

Dr. Adrian Wrigley wrote:
> On Wed, 24 May 2006 17:12:55 +0000, Dick Hendrickson wrote:
[snip, discussion mostly of subscript bounds checking and some
discussion of subroutine calling consistency]

> I think this is an area that Ada really shines.  The standard
> requires numerous checks for consistency at both compile
> time and runtime.  Versions of code that don't match properly
> can't be linked together or can't be run together (as appropriate).
> Using the language gives a feeling of integrity of coding,
> with mistakes often being caught very early on.
> 
> Unfortunately, the language features for integrity cannot
> be added to an existing language without breaking old
> code.  This is because the integrity features are often a result
> of prohibiting "dodgy" code, flawed syntax or misfeatures.

Yes, in Fortran 90 the decision was made to allow complete
compatability with existing standard conforming code.  For
good or bad, old code written in the 60s dealt with 32,000
word memories and, as a result, the standard adopted
features that let memory be reused and viewed in different
ways.  COMMON, EQUIVALENCE, the ability to magically reshape
arrays across the CALL boundary, alternate ENRTY points in
subroutines and functions all, in my opinion, trace their
ancestry to dealing with small memories and slow (or
nonexistent) rotating storage.   Keeping those codes alive
required some compromises.  The need for separate
compilation of 1,000,000 line programs and the use of
well tested existing libraries (often in C or assembly)
basically prevented Fortran from adopting strict CALL
interface rules.   However, I think more and more
libraries are being retro-fitted with a clean module
interface where possible.  So things are getting better.

There's no real excuse for writting a new program
without using modules to specify the interfaces and
this essentially guarantees that the compiler will
do the right thing.  One serious practical problem
with large codes has been compilation cascades.  Any
change to a low-level module almost always forced a
recompilation of everything that used the module, even
if the change had no effect on the interfaces.  This
is mostly due to the way make interacts with the
commonest implementation of modules, I think.  This
will be fixed (or at least changed ;) ) in F2008.

Dick Hendrickson