Path: utzoo!utgpu!attcan!uunet!tank!ncar!ames!killer!texbell!sugar!ssd
From: ssd@sugar.uu.net (Scott Denham)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 88
Summary: Single language environments
Keywords: fortran standards
Message-ID: <2875@sugar.uu.net>
Date: 21 Oct 88 07:20:37 GMT
References: <2045@unmvax.unm.edu> <657@convex.UUCP> <660@convex.UUCP> <15776@agate.BERKELEY.EDU>
Distribution: comp.lang.fortran
Organization: Sugar Land Unix - Houston, TX
Lines: 56

In article <15776@agate.BERKELEY.EDU>, link@stew.ssl.berkeley.edu (Richard Link) writes:
> 
> I did not mean to imply that FORTRAN cannot be greatly improved. What I
> am concerned about is changing the *scope* of the language - from
> something that does a few things well, to something that does a lot of
> things less well. There are penalties for increasing the size of the
> language.
 
No, I didn't think you meant Fortran couldn't be improved (though I have
spoken with folks who think F77 is perfect and should be frozen for
eternity!).  And FORTRAN should certainly NOT be extended to try to do
everything well; I have no desire to write another payroll program in
FORTRAN, and we don't need another PL/I.  The point I was trying to make
is that as the underlying systems get more complex, FORTRAN will have to
be able to do MORE things well to continue to be as useful as it has been.
> 
> My central argument has not been challenged - one should use the
> best tool for the job at hand. Why does your programming staff bend
> F77 rules, when there are other languages like C that could probably
> do those kinds of jobs much better? I guess I don't understand the 
> rationale behind your company using a language not suited for the
> application. This may be more of a management error, rather than a
> FORTRAN shortcoming.
> 
AH, but for the most part, FORTRAN is VERY well suited to the application;
I'm sure something like 99% of the code in our industry has been written
in FORTRAN, and I don't see that changing much.  There are just some 
things that are not so simple in FORTRAN 77 without breaking rules -
and virtually every commercial user I have discussed this with confesses
to using the same "tricks" for things like: 
    Dynamic sizing of arrays/Dynamic aquisition of storage.
    Variable length calling sequences.
    Structures of mixed type, or having to handle varying data representeation
As far as management policy goes, there are lots of good reasons to try
to mimimize the number of languages in use; there's always one or two
applications that work better in another language, but then you are  
"stuck" with it; we were burned by PL/I this way when one guy was allowed
to go off and develop a sizable system in it. He's long gone and nobody
else wants anything to do with PL/I - and if a site wants to run that
one application, they have to shell out something on the order of $500
a month for a PL/I license.  Consider also the cost of training, manuals,
and support tools, and the problems of having to support this code in
a number of data centers around the world. The cost is NOT small.  And
as a last point, some vendors (though I'd never mention IBM by name)
do an absolutly LOUSY job of integrating their language products; the 
thought of trying to get say "C", FORTRAN, and ADA modules linked up
and cooperating without their run-time libraries getting into a major 
war curls my hair!! 
  
> Dr. Richard Link
> Space Sciences Laboratory
> University of California, Berkeley
> link@ssl.berkeley.edu
 
 Scott Denham 
  Western Atlas International