Path: utzoo!mnetor!uunet!steinmetz!ge-dab!codas!pdn!alan
From: alan@pdn.UUCP (Alan Lovejoy)
Newsgroups: comp.arch
Subject: Re: FORTRAN Horror
Message-ID: <2596@pdn.UUCP>
Date: 21 Mar 88 16:41:09 GMT
References: <24861@yale-celray.yale.UUCP> <1135@pembina.UUCP>
Reply-To: alan@pdn.UUCP (0000-Alan Lovejoy)
Organization: Paradyne Corporation, Largo, Florida
Lines: 49

In article <1135@pembina.UUCP> cdshaw@pembina.UUCP (Chris Shaw) writes:
>In article <24861@yale-celray.yale.UUCP> leichter@yale-celray.UUCP (Jerry Leichter) writes:
>I think the reason that the scientific community likes FORTRAN is that the
>scientific community likes FORTRAN. There are huge libraries of code that solves
>most of the boring details of your problem, so all you have to do is code up
>the I/O and the mainline (gross amounts of handwaving here) and bob's your 
>uncle.
>
>Well fine. But it's a software engineering horror, and everyone knows it. Just
>because it's standard to carve a chunk out of an array doesn't mean that this
>is the best way of doing things. Jerry carelessly mentions the possibility of
>doing numerical codes in C, and basically states that things would be no 
>different. Well, I HAVE done this and the benefits are considerable.  I 
>translated a subset of SPARSPAK, a sparse matrix package, to C.

The other reason is that FORTRAN programmers are interested in raw
performance above all else.  They are perfectly happy to twiddle the 
source code to get the maximum performance for each specific problem,
recompile, run the program, twiddle the code for the next similar but
slightly different problem, recompile....  Generic code written using
abstract notation that permits the same object code to work with arrays
(or other collections) of arbitrary size and/or with numbers which can
freely be chosen from among REAL, INTEGER, COMPLEX, matrix, polynomial, 
numeric-valued-function or user-defined values is of little interest to
people whose main concern is performance.  They don't mind having one
subroutine for gaussian elimination of 25 by 132 matrices of 32-bit real
numbers, one for 834 by 1077 matrices of complex numbers, etc.  Does the
next problem require a different size matrix?  That's ok, they'll just
twiddle the code and recompile.  Does the next problem call for complex
numbers using 64-bit reals?  They'll just make a copy of the one for
32-bit reals and use the editor's global replace to change the data 
types as appropriate.  Of course, all code is written for maximum 
performance on the machine which will be used to run it.  When a new
machine with a new architecture comes along, the code will be twiddled
for maximum performance on the new machine.

Performance is an OBSESSION with these people.  Perhaps rightly so in
some or even most cases.  When Ada (Modula-2, C, C++, ML, Oberon,
whatever the latest and greatest language is...) compilers can 
produce significantly faster code than FORTRAN compilers,
even when the full complement of abstraction mechanisms are used,
then you MIGHT be able to interest the FORTRAN crowd in such a language.
Until then, FORGET it.  And even then, learning the new language had
better not take too much time out of these people's busy schedules.
They have REAL work to do (pun intended).

Only half :-)

--alan@pdn