Path: utzoo!utgpu!watmath!clyde!mcdchg!chinet!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!oliveb!sun!chiba!khb
From: khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering)
Newsgroups: comp.lang.fortran
Subject: Re: Why have FORTRAN 8x at all?
Keywords: FORTRAN PL/I kludge
Message-ID: <75320@sun.uucp>
Date: 30 Oct 88 03:08:09 GMT
References: <388@ubbpc.UUCP> <16187@agate.BERKELEY.EDU> <599@quintus.UUCP>
Sender: news@sun.uucp
Reply-To: khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering)
Organization: Sun Microsystems, Mountain View
Lines: 125

In article <599@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <16187@agate.BERKELEY.EDU> link@sag4.ssl.berkeley.edu (Richard Link) writes:
>>In article <388@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes:
>>>why is there an effort to make up a new standard at all?
>>
>>The reason for a new standard is:
>>(1) there is a huge investment in already written code

>But the *old* standard is sufficient to protect that.

Nonsense. If I can't use the tools developed in the "old language", I
have to rewrite them in the new langauge. This is not protecting an investment.
>
>>(2) FORTRAN is the most useful (existing) language for number crunching.
>Again, the *old* standard is sufficient to protect that (if true).

(if true ?) sheer number of lines of code produced each year, combined
with the constant research into better fortran optimization techniques
would seem to demonstrate this. Know of a single vendor of high
performance computers who doesn't produce a fortran compiler FIRST ?

btw: ditto on the failure of the old standard to protect the future

>
>>Why should I, or anyone else, rewrite millions lines of code simply
>>because somebody else, who has not programmed in FORTRAN for ten years,
>>thinks a new language is more desireable?
>Indeed, why should you?  People invent new languages all the time; you
>didn't have to rewrite your Fortran code when Pascal was invented, nor
>when C was invented, and not even when ADA was invented.  As long as
>faithful implementations of the old language are still available, your
>code will continue to run, and if we're a wee bit realistic about it,
>that's the *only* thing that will protect your existing code.

Note that off all the hundreds of new languages developed, only C has
had any real impact on a real commerical basis. Many scientific
projects last more years than the new hot language on the block does.
Writing code which must last years requires a stability that your
proposal does not provide.
>
>Just how hard it will be to compile F8X I don't know.
>All I can say is that I know several dozen programming languages, including
>APL and DAP FORTRAN, and the Feburary '87 draft of F8x described a language
>that I found bewilderingly complex.  I liked most of the new features, it
>was just that they had been bodged together in the most apalling way so that
>the new language could claim F77 as a subset.  We can be reasonably
>confident that for three to five years after the standard is settled the
>new compilers will be sufficiently buggy that you will have to rewrite your
>old code to use the new features (because those will be the bits that work!).
>Unless, of course, you hang on to your old compilers until the new ones
>settle down.  That's what keeps happening with COBOL:  some of the COBOL
>programmers I know didn't switch over to COBOL 74 until in the 80s because
>not only were the compilers buggy, but there turned out to be one or two
>serious ambiguities in the standard which different compiler writers had
>in good faith interpreted different ways.

The new language is constructed such that most users will simply not
have to know how to use it (like how to write code with keyword
arguement passing and operator overloading). Those experts tasked to
create easy to use libraries need these features, and these features
make it simpler for naive users to write new code. 

Your holding up COBOL as an example is a good point, as old COBOL code
cannot always run on new compilers. By construction this is not true
of F88. Thus whenever a user switches over the cost of switching is low.

>
>>why would CERN, the European particle accelerator establishment, want
>>to throw away all that code?
>As long as they have a compiler for F77, and whatever new language they
>are using will let them mix F77 routines with Utopia-99, why would they
>_have_ to throw away all that code?

Because in a multi-vendor environment this simply doesn't work. Within
any vendor's product line it often does; but no large scientific
organization is so deeply comitted to a single vendor. Multilanguage
programming is wonderful....but all vendors have to provide identical
versions of each language and all have identical idiocyrancies in
arguement passing between languages....I doubt this sort of
meta-standardization will happen in my lifetime.

>
>>Now that I've said all this, I wonder: are you being facetious?
>Probably not.  Were you?  There are two separate propositions:
>
>	(a) People with an investment in F77 code should not have to
>	    abandon it.
>	(b) The best possible standard language for numerical work
>	    must include F77 as a subset.
>
>I think it is fairly clear that (b) is false, if by "best" we mean things
>like comprehensible, easy to optimise, &c, and that (a) can be satisfied
>whether there is an F8x or not and whatever it looks like.  But as a
>*practical* matter of persuading people to move up, calling the new
>language Fortran is a neat trick, and if you also want

It is not clear that b is false. It should be clear that a is only
true if we give up on making any progress.

>	(c) People doing numerical work should be able to do all of it
>	    with just one compiler
>_then_ (a) and (c) entail (b).  But you can't get there without (c).

If they can't, they won't be able to change platforms, or they will
have to give up on using tools developed for one project in another.
Furthermore those that adventure into new exotic languages will
produce tools which no one will be able to employ...as "most"
scientific users are scientists first, programmers second. 
>
>Don't take this message as knocking F8x, whatever it ends up like.
>I appreciate the practical forces behind it, and am profoundly thankful
>that the thankless task of working on the standard is not mine.
>I just wanted to make it clear that Hutchinson was also being sensible.

I think Hutchinson was being serious. That is what is scary.








Keith H. Bierman
It's Not My Fault ---- I Voted for Bill & Opus