Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Missing the whole point (the Fortran vs. C debate)
Message-ID: <7552@lanl.gov>
Date: 1 Dec 90 21:47:11 GMT
References: <28548@usc>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 73

From article <28548@usc>, by ajayshah@almaak.usc.edu (Ajay Shah):
> [...]
> The essential reason why I get repelled fortran, dusty decks 
> in fortran and the mindset of traditional (read: went to graduate
> school before 1975) fortran programmers is the terrible
> look-and-feel.  [...]

You are right in changing the subject line.  This has little to do
with the Fortran vs. C debate.  Especially since the look-and-feel
of C is much worse for the problem domain appropriate to Fortran.

> [...]           Beautiful (read: efficient on my time)
> programming comes with a rich appreciation of how algorithms +
> data structures makes programs, in careful attention to the way
> modules interact, in fine-tuning the scope and visibility of data
> across modules, in building really reuseable modules with sterile
> interfaces, etc.  [...]

You are thinking of programming as only a self-directed activity.
If _you_ are the only end user, then your time is the only human
efficiency consideration.  Most programmers are concerned with
providing a useful capability for a large set of end users (including
themselves).  The effect of a slow program on those end users is
too complicated to be simple measured by the additional CPU time
cost.  If a program takes an hour to run, I will use it differently
(and less flexibly) than if it takes only a few minutes to run.
Fast calculations are changing the way people work in all sorts
of problem domains.  Fast simulations, for example, allow designers
to iterate several ideas through the code (basing each new try on
the results of the previous one) and are improving the design of
everything from aircraft to computers.

If there were a widely available language that allowed the programmer
to do all the things you mention above and _still_ generated fast
code, there would be no question about switching to it.  But the
economics of computing still values speed over programmer time
for most of the interesting problem domains.  The increase in
raw speed of computers is not likely to change that much since
this only expands the domain of viable problems to a larger
set.  There are few problems for which code is already as fast
as anyone will ever need.  End-user expectations rise as fast
as the hardware improves.

> [...]                                      I've seen
> single-file-programs in fortran written two years ago (not the
> dark ages of the 60s) of 10000 lines!  (not more than a few
> hundred lines of comments, obviously).  That is disastrous, and
> that is the essence of the problem to me.

This is ambiguous.  A single file may contain any number of
independent Fortran procedures (so your apparent assumption
that the program in question is not modular is faulty).
Further, you didn't tell us what the program _does_, so
we can't determine whether 10000 lines is overly large or
remarkably compact.  Complex problems require large programs:
there is no "Royal road" to good programs.

But, let us assume that you mean that the program was really a single
procedure.  This still doesn't mean that it was disastrous.  It may
have been carefully crafted using all the techniques that you support
and _then_ all the procedure calls were "inlined" for speed.  This is
not a bad technique - it will only disappear when "inlining" becomes
a widely available feature of programming languages.  There is no
a priori reason that Fortran could not be extended to do this (it is
one of the things that Fortran Extended's 'internal' procedures should
be able to do).

In any case, I am in complete agreement that language designers
should try to include features that promote more efficient coding
and maintenance.  But so far, no language is widely available
which does so AND is as efficient as Fortran-like languages.

J. Giles


Brought to you by Super Global Mega Corp .com