wgh@ubbpc.UUCP (William G. Hutchison) (10/28/88)
I haven't programmed seriously in FORTRAN for a decade or so, so maybe some FORTRAN advocates can tell me something: why is there an effort to make up a new standard at all? It seems to me that if folks keep kludging up FORTRAN to make it more "modern", they arrive at a baroque mess that serves nobody well. Modern FORTRAN has been tried before: it was called PL/I and it flopped miserably. Wouldn't the numerical computation community be better advised to find or develop a modern language, e.g. something like Modula-2 or occam or whatever (insert your favorite BNF here), possibly with the addition of some stuff to facilitate numerical work, then to put the effort into writing good FORTRAN-to-UTOPIA-99 translators. I just don't see that making more complex, kludgy FORTRANoid languages is a good use of time and money. -- Bill Hutchison, DP Consultant rutgers!cbmvax!burdvax!ubbpc!wgh Unisys UNIX Portation Center "What one fool can do, another can!" P.O. Box 500, M.S. B121 Ancient Simian Proverb, quoted by Blue Bell, PA 19424 Sylvanus P. Thompson, in _Calculus Made Easy_
ok@quintus.uucp (Richard A. O'Keefe) (10/30/88)
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.
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (10/30/88)
In article <388@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > > I haven't programmed seriously in FORTRAN for a decade or so, so maybe some >FORTRAN advocates can tell me something: why is there an effort to make up >a new standard at all? > It seems to me that if folks keep kludging up FORTRAN to make it more >"modern", they arrive at a baroque mess that serves nobody well. > Modern FORTRAN has been tried before: it was called PL/I and it flopped >miserably. CS types (i.e. all of US ACM members :>) are always talking about reuseable tools. FORTRAN users have them. In spades. Giving up all the existing software is not a reasonable thing to do. PL/I was NOT a modernized FORTRAN. It was conceived as a language to replace FORTRAN & COBOL. Of course, it failed at both. F88 is NOT just a set of kludges. I stongly recommend Metcalf and Reid's F8x explained. To summerize all the years of effort in a couple of words (take with salt) : f88 is a language designed to accomodate the needs of scientific computing. If another language satisfied this community, this would be unecessary...but nothing comes close. > Wouldn't the numerical computation community be better advised to find or >develop a modern language, e.g. something like Modula-2 or occam or whatever >(insert your favorite BNF here), possibly with the addition of some stuff >to facilitate numerical work, then to put the effort into writing good >FORTRAN-to-UTOPIA-99 translators. As above. This is much too expensive, nor is it obvious that f88 is not "a modern language". Overloaded operators, modules, abstract datatypes, special numericalenvironment functions, and the rest seem to fit the bill". F88 is not utopia 99; but it is modern. >I just don't see that making more complex, kludgy FORTRANoid languages is >a good use of time and money. I just don't see that throwing about $1+ Billion dollars of software is a viable alternative. Nor that anything on the market comes close to F88 as a language that supports scientific computing. F88 sans the old f66 features would be close to what you suggest. If the current pace of development holds up this sort of thing MAY come to pass, in another 20-30 years. Then again, we may chose to keep computed goto and arithmetic if forever, to help remembe rthe early days "when men carried swords of stone". :>> Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (10/30/88)
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
psmith@mozart.uucp (Presley Smith) (10/30/88)
In article <75320@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes: >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 The mixture of old and new features will provide new challenges for the vendors that must optimize code. The new standard has certainly NOT been written with optimization in mind. One of the foremost researchers in Fortran optimization told me last year that he should be FOR the proposed new language because it would keep him busy for the next few years consuting with compiler writers on the problems with optimizing the new constructs. He was against the proposal because he did not see the real benefit to the Fortran community. (Text deleted) >> >>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. > One of the major things that IBM complained about in their ballot was that proper use of Fortran 8x would not preserve the investment in user training. As has been noted, it is a complex language and users will have to be trained to use it and use it properly. There will be a mixing of old and new constructs so that programs that people have worked with for years will change in ways that programmers will have to get used. This mixture of constructs will cause problems in sustaining code. I'm not sure what "experts" you expect are going to create these libraries, etc. It will take years for such facilities to become widespread and since they will NOT be defined by a standard, people who use them will find their code is no longer portable. I don't believe that Fortran 8x will every make it "simpler for naive users to write new code." That's like saying it's easy for the naive user to write new code in Ada because a lot of packages have been defined... it's just not true. >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. > One of the major debates in the X3J3 committee today is whether to start with FORTRAN 77 as a base document and add the 8x constructs to produce the next version of 8x for public review, or to start with the current version of 8x and remove and modify portions to respond to public review. Why this debate? Because so much has been changed in the proposed 8x that there are members of the committee that are NOT convinced that all of FORTRAN 77 has been preserved. They claim that the only way at this point to insure that 8x is really upwardly compatible with FORTRAN 77 is to start with FORTRAN 77 and re-add and integrate the 8x features back into it. These members of X3J3 don't believe that there has been enough effort to insure that FORTRAN 77 has not been changed in the process of trippling the size of the FORTRAN 77 document to produce the 8x document. Just as with the arguments on COBOL, there will be different vendor interpretation of Fortran 8x that will cause problems with portability. Since no one has implemented at 8x today, we currently don't even know where those problems will occur. (Text deleted)
wgh@ubbpc.UUCP (William G. Hutchison) (11/01/88)
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: > > I haven't programmed seriously in FORTRAN for a decade or so, so maybe some > >FORTRAN advocates can tell me something: 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 > (2) FORTRAN is the most useful (existing) language for number crunching. > 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? Your arguments are certainly > not going to get me to change to something else. > > Now that I've said all this, I wonder: are you being facetious? Dr. Link: No, I am not facetious, and you misunderstood one of my points: I am NOT advocating that you change to another programming language. My question is Why not leave FORTRAN 77 alone and stop messing with FORTRAN? Here is the historical paradigm I am looking at: Algol-60 was a breakthough, excellent language; widely used as a publication language and used in Europe as a practical language. So a committee decided to "improve" Algol-60 to Algol-68. You may recall the result: Algol-68 was "improved" to the point of being unusable. Very few implementations ever were finished: hardly anybody ever managed to get through the language spec. IBM decided to "improve" FORTRAN and COBOL: they produced PL/I: another semi-usable mess. From the comments IN THIS GROUP, I conclude that FORTRAN 8x is evolving into another committee-designed mess, which I doubt sincerely will serve anybody well. So I ask again, why have FORTRAN 8x at all? (not facetious!). As for your point about preserving your investment in FORTRAN-66 or FORTRAN-77, I suggest that you keep on programming in FORTRAN-66 or FORTRAN-77! -- Bill Hutchison, DP Consultant rutgers!cbmvax!burdvax!ubbpc!wgh Unisys UNIX Portation Center "What one fool can do, another can!" P.O. Box 500, M.S. B121 Ancient Simian Proverb, quoted by Blue Bell, PA 19424 Sylvanus P. Thompson, in _Calculus Made Easy_
wgh@ubbpc.UUCP (William G. Hutchison) (11/01/88)
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? [ illogical arguments deleted ] > I just wanted to make it clear that Hutchison was also being sensible. Thanks! Glad to see somebody here thinking with neurons rather than their glands! You understood my point that there is no need to rewrite FORTRAN-77 code just because somebody proposes a "new, improved" vastly more complex "standard". By the way, here is some more discussion on how Algol-60 was "improved": Algol-60 was "improved" to Algol-68 by a committee and the result was an embarrassing debacle. Algol-60 was really improved by Niklaus Wirth: Algol-60 -> Algol-W -> Pascal -> Modula -> Modula 2 -> ... -> ??? Note that real improvements in language design seem to come from individuals or small groups, not large committees! More examples of real improvements (by individuals) BCPL -> B -> C -> C++ Beware of committees of politicians bearing standards! -- Bill Hutchison, DP Consultant rutgers!cbmvax!burdvax!ubbpc!wgh Unisys UNIX Portation Center "What one fool can do, another can!" P.O. Box 500, M.S. B121 Ancient Simian Proverb, quoted by Blue Bell, PA 19424 Sylvanus P. Thompson, in _Calculus Made Easy_
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (11/02/88)
In article <391@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: >In article <16187@agate.BERKELEY.EDU>, link@sag4.ssl.berkeley.edu (Richard Link) writes: > > Here is the historical paradigm I am looking at: > Algol-60 was a breakthough, excellent language; widely used as a publication >language and used in Europe as a practical language. So a committee decided >to "improve" Algol-60 to Algol-68. You may recall the result: Algol-68 was >"improved" to the point of being unusable. Very few implementations ever were >finished: hardly anybody ever managed to get through the language spec. > IBM decided to "improve" FORTRAN and COBOL: they produced PL/I: another >semi-usable mess. x3j3 was well aware of these previous diasters. This is why it insisted that f8x (now, by fiat of wg5, f88) accept all existing f77 compliant code. This was not true of algol-68. PL/1 was compatible with no previous (or future) language. Neither is a good model for understanding f88. > From the comments IN THIS GROUP, I conclude that FORTRAN 8x is evolving into >another committee-designed mess, which I doubt sincerely will serve anybody >well. There is a very natural tendency for posters to come from the ranks of the unhappy..this colors the impression.. If I had not been using fortran, and had not read metcalf and reid's book AND the proposed standard (and to be fair, several years of committee meetings) I would not feel competant to pass judgement on the standard. > So I ask again, why have FORTRAN 8x at all? (not facetious!). Because the cost of developing scientific code is much too high. Because systems evolve or die. Because we know there are better solutions. Because a large number of people have demanded change. Because lack of a new standard breeds ever more complex vendor extensions. > As for your point about preserving your investment in FORTRAN-66 or >FORTRAN-77, I suggest that you keep on programming in FORTRAN-66 or >FORTRAN-77! The point is how to preserve the investment, but not continue to pay the price of using a 1960's language (with a couple of 1970's minor mods). Committees may not create perfect standards, but there is no alternative. With the possible exceptions of C and APL, no language cooked up by a single individual or tiny team has proven useful to a wide audiance (I include pascal (which mututated radically on its way to even limited sucess as a commercial language, and forth which continues to serve a very limited audiance) (many will argue that APL has not been an exception either). Personally I think x3j3 was faced with a nearly insoluable problem. How to (a) plan for orderly evolution (b) provide an relatively smooth path for upgrading to a modern language (c) provide all the features needed by a very diverse user community. Anyone who can't find fault with the standard simply isn't trying hard enough. The question is: which (if any) objections/complaints were not aired years ago? x3j3 may not have dealt with them as everyone might have liked; but dealt with them they did. So when are we gonna call it wrap, do it; and then start discussing the next standard ? Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (11/02/88)
In article <392@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > >Thanks! Glad to see somebody here thinking with neurons rather than their >glands! Note that the fellow who agrees with you hasn't used fortran for 10 years. If I didn't use my car, I might not care that the engine oil had been removed. :> > You understood my point that there is no need to rewrite FORTRAN-77 >code just because somebody proposes a "new, improved" vastly more complex >"standard". It should be noted (* sigh *) that the new improved vastly more complex standard does NOT REQUIRE YOU TO REWRITE YOUR CODE. This is one of the reasons it is complex and large. NO REWRITING. NONE. > By the way, here is some more discussion on how Algol-60 was "improved": >Algol-60 was "improved" to Algol-68 by a committee and the result was an >embarrassing debacle. > Algol-60 was really improved by Niklaus Wirth: > Algol-60 -> Algol-W -> Pascal -> Modula -> Modula 2 -> ... -> ??? Right. Which is why no algol code was portable to -W. Nor was either usable under Pascal. None of any of them under modula. And again for modula II. Wirth has contributed much to computer science, but creating languages suitable for long term development of production code...I think the record speaks for itself. > >Note that real improvements in language design seem to come from individuals >or small groups, not large committees! But committees are responsible for languages being useful to large groups of people for long periods of time. It is all right for students to rewrite the codes of yesteryear, this is exactly what school is all about. It is not reasonable for industry to act in a similar fashion. When it comes to pure research, small groups are ideal (note that Wirth rarely worked along. grad studentor equiv s did the implementations). When the needs of the many must be weighed there is no substitute for a committee. This is unfortunate, but it appears to be true. > > More examples of real improvements (by individuals) > > BCPL -> B -> C -> C++ > > Beware of committees of politicians bearing standards! > Beware of new wave languages, few endure the test of time. >P.O. Box 500, M.S. B121 Ancient Simian Proverb, quoted by >Blue Bell, PA 19424 Sylvanus P. Thompson, in _Calculus Made Easy_ Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
oglesby@m7.multiflow.COM (Jose Oglesby) (11/02/88)
In article <392@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes:
Algol-60 was really improved by Niklaus Wirth:
Algol-60 -> Algol-W -> Pascal -> Modula -> Modula 2 -> ... -> ???
BCPL -> B -> C -> C++
Beware of committees of politicians bearing standards!
What about the FORTRAN 77 Standard which now has so many defenders?
Wasn't that produced by a committee? Yes, one should beware, but
one should also try to keep an open mind. Just because committes
have generally failed in the past does not mean they must continue
to fail. In fact, I am very hopeful for the C and Scheme efforts.
The most important common thread that ties these efforts together
is the attempt to standardize existing practice. In the case of
ANSI C there is also an attempt to "modernize" the language. This
has been done in a restrained manner by not adding too many new
constructs or concepts. In "modernizing", one can not go too
far. I don't think the C community would be too happy if ANSI C
were the same as C++. ( Personally, I would have approved ).
Now let's look at the 8X effort. I beleive that so far the
committee has done a good job under difficult circunstances.
There are problems in the existing draft but it can be rescued.
The negative comments in comp.lang.fortran lately have not been very
helpful. ( i.e. It is bigger than Ada! Why have it at all? )
Those people who claim that the F8X language is too big should
come up with specific things they feel should be dropped from
it. To those who question the need for a standard I would
point out the need to standardize existing practice so as
to obtain more portable code.
Actually one of the problems with the standard is its failure
to address some existing practice. The bit strings and include
statement omissions should be rectified. The include statement
problem could be handled through a supplementary standard for
a pre-processor.
My favorite candidate for deletion from F8X is the notion
of precission specification. As the IEEE standard becomes
more widespread the need for this feature lessens.
Well, that's all for now. Sorry for the long post.
--
Jose Oglesby
oglesby@multiflow.com Multiflow Computer
or oglesby@mfci.uucp 175 North Main St.
or ...!uunet!mfci!oglesby Branford CT 06405 (203)-488-6090ssd@sugar.uu.net (Scott Denham) (11/04/88)
In article <75769@sun.uucp>, khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) writes: ( Extensive discussion of "Why Revise Fortran" deleted) > Because lack of a new standard breeds ever more complex vendor extensions. > > Keith H. Bierman To my way of seeing it, this point alone is enough to answer the whole question of "why" - if Fortran 77 was such a great tool for the applicastion writer, *WHY* are there so many vendor extentions? Surely these folks don't just wake up one morning and decide it would be nice to add say, a new loop construct (DO WHILE ?) to their compiler. These extensions cost the developers a signifigant amount of money. This speaks for the users driving the market to provide these new features. Clearly it is to the benefit of all to standardize the way these extentions are handled so that Fortran remains a language and not just a concept. What's next.... "Turbo Fortran" ???? Scott Denham Western Atlas International Houston, TX
wgh@ubbpc.UUCP (William G. Hutchison) (11/04/88)
In article <2947@sugar.uu.net>, ssd@sugar.uu.net (Scott Denham) writes: > In article <75769@sun.uucp>, khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) writes: > ( Extensive discussion of "Why Revise Fortran" deleted) > > Because lack of a new standard breeds ever more complex vendor extensions. > [ ... ] *WHY* are there so many vendor extentions? Surely these folks don't ^^^^^^^^^^ extensions > just wake up one morning and decide it would be nice to add say, a new > loop construct (DO WHILE ?) to their compiler. Remember the Conspiracy Theory of vendor-customer relations [ :-) ] Vendors do not implement non-standard extensions to their products to BENEFIT customers, but to trap them into writing non-portable code, thereby to keep them from converting their programs to some other vendor's systems. If certain companies like Itty Bitty Monopoly did not have non-portable constructs like that as a barrier to porting AWAY from their systems, how could they justify such an outrageous high price for their systems? -- Bill Hutchison, DP Consultant rutgers!cbmvax!burdvax!ubbpc!wgh Unisys UNIX Portation Center "What one fool can do, another can!" P.O. Box 500, M.S. B121 Ancient Simian Proverb, quoted by Blue Bell, PA 19424 Sylvanus P. Thompson, in _Calculus Made Easy_
d25001@mic.UUCP (Carrington Dixon) (11/06/88)
In article <394@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > > If certain companies like Itty Bitty Monopoly did not have non-portable >constructs like that as a barrier to porting AWAY from their systems, how >could they justify such an outrageous high price for their systems? > If you were talking about their PL/I, I might agree with you. In the context of FORTRAN, I find the statement puzzling. VS FORTRAN is fairly lightly extended as compared to some others -- though there seem to be more extensions with each release. The VS FORTRAN manuals are _very_ good about flagging all the extensions as such -- a refreshing change from those of a lot of vendors. There is even a compiler option to flag (as warnings - I believe) all occurances of those features not sanctioned by X3.9-1978. Strange behavior for the product of a company that is trying to trap the user into writing non-portable code. Carrington Dixon UUCP: { convex, killer }!mic!d25001
bill@hcx2.SSD.HARRIS.COM (11/09/88)
> Remember the Conspiracy Theory of vendor-customer relations [ :-) ] > Vendors do not implement non-standard extensions to their products > to BENEFIT customers, but to trap them into writing > non-portable code, thereby to keep them from converting their programs > to some other vendor's systems. This "Theory" may have been true of some vendor(s) at one time, but I think it is safe to say it is total bunk now. Competition for business is very keen, but the user community (except for PCs) is not growing that rapidly. Today's buyers are yesterday's (and last decade's) buyers; many new sales are either upgrades of old machines or for expansion of computing facilities. This means that if a vendor wants new business, it has to be taken away from some other vendor. In that situation, the first thing the user asks is, "How difficult will it be to port X's code to your machine?" That is why many vendors have been busy these last few years implementing other vendors' extensions: we have to to survive. Are vendors against standardization? NO WAY! The non-portability issue works against us (at least now) far more often than it works to our advantage.
sow@eru.mt.luth.se (Sven-Ove Westberg) (11/09/88)
In article <75320@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes: |would seem to demonstrate this. Know of a single vendor of high |performance computers who doesn't produce a fortran compiler FIRST ? ALL that don't write the operating system and other utilities in fortran. Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden. UUCP: {uunet,mcvax}!enea!cad.luth.se!sow ARPA: sow%cad.luth.se@ucbvax.berkeley.edu (only dumb ARPA mailers) Internet: sow@cad.luth.se Bitnet: sow%cad.luth.se@sekth
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (11/10/88)
In article <1265@luth.luth.se> Sven-Ove Westberg <sow@cad.luth.se> writes: >In article <75320@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes: > >|would seem to demonstrate this. Know of a single vendor of high >|performance computers who doesn't produce a fortran compiler FIRST ? > >ALL that don't write the operating system and other utilities in fortran. > Many high performance computers have the utilities (and much of the OS) running on other processors (viz CDC's PP's, Cydrome's IP's, etc.). Even if something is written for in house use, the first REALEASED product (with a real optimizer) is usually the FORTRAN compiler. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
anw@nott-cs.UUCP (11/11/88)
In <391@ubbpc.UUCP>, wgh@ubbpc.UUCP (William G. Hutchison) writes, amongst other things (in the Fortran group): > Here is the historical paradigm I am looking at: > Algol-60 was a breakthough, excellent language; widely used as a publication > language and used in Europe as a practical language. So a committee decided > to "improve" Algol-60 to Algol-68. You may recall the result: Algol-68 was > "improved" to the point of being unusable. Very few implementations ever were > finished: hardly anybody ever managed to get through the language spec. and follows up his own article in <392@ubbpc.UUCP> with: > By the way, here is some more discussion on how Algol-60 was "improved": > Algol-60 was "improved" to Algol-68 by a committee and the result was an > embarrassing debacle. > Algol-60 was really improved by Niklaus Wirth: > Algol-60 -> Algol-W -> Pascal -> Modula -> Modula 2 -> ... -> ??? > > Note that real improvements in language design seem to come from individuals > or small groups, not large committees! And so are myths perpetuated. Let's see: "A committee decided" -- well, not exactly. A committee was *charged with* developing Algol 60, in the light of the deficiencies in that language which had become apparent with use. Sound familiar? As is well-known, the sub-committee which eventually spawned '68 did not do so without causing a certain amount of controversy. Sound familiar? "A68 was unusable" -- well, not exactly. It was for some years the preferred language at a number of institutions, including this one. From 1972 to 1978, virtually all my own programs were written in A68, ranging from toys up to major projects of many thousand lines. Only yesterday I heard of a new major program for the semantic analysis of programs written in Pascal, Ada, Fortran, etc., consisting of some 70000 lines of A68. I *personally* taught over 1000 students in this Department Algol 68 as their first programming language; my *personal* opinion (which you may take with as many grains of salt as you like) is that A68 is easier to teach, *and* to learn, *and* to use, than A60 (which we used before 1972), and than Pascal (which we eventually were forced to switch to). Purely incidentally, in all the tests known to me, A68 programs benchmarked faster than their Fortran equivalents; advances in compiler technology may have changed that picture in the '80s. A68 is *still* in wide use in many places. "Very few implementations finished" -- well, not exactly. The current (and last [:-(]) Algol Bulletin lists 7 *current* implementations "which you can actually obtain and use", running on at least 20 different machine architectures, including all the popular ones, under at least 20 different operating systems, ditto; except indeed that the 68S which runs on "my" current system (PDP 11/44, Unix V7) doesn't get a mention. I guess those figures will be beaten by a few of the most popular languages, but not by many. "[unreadable] language spec" -- well, not exactly. The Revised Report was, for a while, routinely taught to our CS specialists, and they seemed to do OK in the consequent exams. *I* learned A68 from the Reports; they certainly weren't light bed-time reading; but no harder than the average graduate text. For the non-specialists, the difficulty of the Report is irrelevant; they learn from the more elementary texts. Just as every serious user of C "has" to read K&R, while ordinary users learn C from easier books. "embarrassing debacle" -- well, not exactly. Some of the opponents of A68, including some of the proponents of Pascal and other rivals, would have you think so. Do you, does anyone, have any *evidence*? How would you rate the relative importance and influence of A68 compared with, say, Simula, APL, Forth, Snobol, to pick a few perfectly respectable languages at random? Why should you (or anyone) think of A68, but not zillions of other languages, as an ED? "A60 really improved by NW" -- well, perhaps. It's debatable, but *I* would agree that Pascal, Modula2, etc are more useful languages than A60; but the implication is that they are better, too, than A68. They just aren't. They *really*, *really* aren't. Better PR job, yes. The point of relevance to Fortran 88 is that you certainly shouldn't think that design by individual is good, and by a committee is bad. Either can be good or bad. But standardisation *certainly* is a committee job, as C, Pascal and Fortran, to name but three, have found recently; no one person, no matter how talented, has the necessary width of expertise. [I've added "comp.lang.misc" to the groups for the A68 relevance; please consider carefully where you direct any follow-ups. -- ANW] -- Andy Walker, Maths Dept., Nott'm Univ., UK. anw@maths.nott.ac.uk