Path: utzoo!utgpu!watmath!clyde!mcdchg!chinet!att!pacbell!lll-tis!lll-winken!arisia!quintus!ok From: ok@quintus.uucp (Richard A. O'Keefe) Newsgroups: comp.lang.fortran Subject: Re: Why have FORTRAN 8x at all? Keywords: FORTRAN PL/I kludge Message-ID: <599@quintus.UUCP> Date: 29 Oct 88 23:31:03 GMT References: <388@ubbpc.UUCP> <16187@agate.BERKELEY.EDU> Sender: news@quintus.UUCP Reply-To: ok@quintus.UUCP (Richard A. O'Keefe) Organization: Quintus Computer Systems, Inc. Lines: 63 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. >(2) FORTRAN is the most useful (existing) language for number crunching. Again, the *old* standard is sufficient to protect that (if true). >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. 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. >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? >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 (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). 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.