Path: utzoo!utgpu!attcan!uunet!husc6!mailrus!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 88
Summary: We need an efficient versatile language
Keywords: fortran standards
Message-ID: <977@l.cc.purdue.edu>
Date: 21 Oct 88 13:27:24 GMT
References: <2045@unmvax.unm.edu> <657@convex.UUCP> <660@convex.UUCP> <15776@agate.BERKELEY.EDU>
Distribution: comp.lang.fortran
Organization: Purdue University Statistics Department
Lines: 51

In article <15776@agate.BERKELEY.EDU>, link@stew.ssl.berkeley.edu (Richard Link) writes:
> In article <2870@sugar.uu.net> ssd@sugar.uu.net (Scott Denham) writes:
> >In article <15744@agate.BERKELEY.EDU>, link@stew.ssl.berkeley.edu (Richard Link) writes:
> >> *MY* biggest problem with F88 is that it looks like FORTRAN was
> >> hijacked by a bunch of academic Pascal/C advocates who insist on
> >> turning it into an all-purpose language, instead of the efficient
> >> number cruncher it was designed to be.
> >> 
> >Now I'm certainly not defending the 8x standard as it exists today, but 
> >I do think that FORTRAN needs to become more of an "all-purpose" language
> >than it is in it's present form, if it is to survive.  Consider the 
> >dilemma the company I work for faces :  We have two "types" of FORTRAN
> >coders - researchers, who are trying to invent and refine new whiz-bang
> >techniques to find oil, and development programmers, who are attempting to
> >incorporate the good ideas of these researchers into stable, efficient,
> >user-friendly, veratile code (for the most part, the researcher's code is
> >none of these things).
> 
> 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.

I find C, with all its disadvantages, better than Fortran because of all
the things not present in Fortran.  I believe that some of them are addressed
in Fortran 8x, but probably not enough.

For good programming, it is necessary to have a versatile language.  Costs
of subroutine calls are high.  It is clearly impossible to write one line
of code in Fortran and the next line in C.  C has left too much out, also.

The only penalties for increasing the size of the language are the size, and
to a lesser extent the speed, of the compiler.  If you are producing a non-
trivial program, these costs are likely to be irrelevant.  It also may be
necessary to explicitly type all variables, instead of using default types.
Many source programs already do this to avoid errors.

All of the present languages deny the programmer the power of the machine.
If execution time is at all important, this is criminal.  Machine structure
is simpler than Fortran (any machine).  Of course, some things will be non-
portable.  This is not the catastrophe that some may think.  A few comments
can explain why the non-portable parts are and what they do.  If they only
constitute a small part of the program, the problems will not be great.

However, the portable problems arising out of the deficiencies of Fortran
are great, and should be addressed.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)