Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!agate!stew.ssl.berkeley.edu!link
From: link@stew.ssl.berkeley.edu (Richard Link)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 88
Keywords: fortran standards
Message-ID: <15776@agate.BERKELEY.EDU>
Date: 20 Oct 88 22:00:12 GMT
References: <2045@unmvax.unm.edu> <657@convex.UUCP> <660@convex.UUCP> <15744@agate.BERKELEY.EDU> <2870@sugar.uu.net>
Sender: usenet@agate.BERKELEY.EDU
Distribution: comp.lang.fortran
Organization: University of California, Berkeley
Lines: 35

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.

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.

Dr. Richard Link
Space Sciences Laboratory
University of California, Berkeley
link@ssl.berkeley.edu