Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!mailrus!iuvax!pur-ee!j.cc.purdue.edu!mace.cc.purdue.edu!tsh From: tsh@mace.cc.purdue.edu (Greg Kamer) Newsgroups: comp.lang.fortran Subject: Re: Fortran 88 Summary: complexity and users - my 2 cents Keywords: fortran standards Message-ID: <894@mace.cc.purdue.edu> Date: 21 Oct 88 16:30:54 GMT References: <2045@unmvax.unm.edu> <657@convex.UUCP> <660@convex.UUCP> <15776@agate.BERKELEY.EDU> Distribution: comp.lang.fortran Organization: Purdue University Lines: 126 Article 779 of comp.lang.fortran: 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). This strikes a VERY familiar chord! The group I work for consists of about 30 researchers who want to solve THEIR problem, don't want to take the time to generalize the code and document it properly, and yet feel perfectly justified about complaining when something I end up having to install for general use doesn't solve the next problem that is encountered. I maintain about 300,000 lines of very quickly mutating code in about 25 major programs and a bunch of ancillary programs for the macromolecular crystallography group at Purdue. We use about 1/2 of the time on the university's Cyber 205, and the ability to write clean, fast code with a nice user interface is critical to our productivity. The division between researchers who want a simple, easy-to-learn language and the requirements of making the code run fast enough while part of a large package would be impossible to deal with in "pure" Fortran 77 for the problems we deal with. Fortran 88 makes several very important steps toward curing this problem. The most important to us in terms of number crunching are the allocatable arrays and vector syntax. The process of integrating all of this into packages demands that I either 1) use Fortran 77 syntax and end up with hard to follow code (doing database oriented work and making good interactive menus is not nearly as easy or clear in Fortran as it is in, say, Pascal or C). 2) write it in another language, in which case nobody else here will be able to read it The record construct in particular DOES make this a more general purpose language (we still need pointers!). This is good, because we are moving away from separate number crunching programs that require a painfully intimate knowledge of the operating system to use to fully integrated packages designed to be used by a non-programmer. Integrating the original pieces and parts in a clean manner will be a lot easier with Fortran 88. In other words, what we want to do with the programs has not changed, but our expectations of the quality of the man/machine interface have risen. Its time to come out with a language that has evolved to make that easier. Hardware and user expectations have come a long, long way in 20 years. Fortran hasn't. There are 2 ways of looking at the complexity of the proposed standard. A pessimist would say that you are making the language too complex and that it will be harder to implement and learn. An optimist would say the the language will be much more powerful than the current standard and will allow us to cleaner and more transportable code. My own feelings : 1) It will make it a lot easier for people who have to put together large programs from scraps written by people who can barely program. 2) The same people who took the time to learn Fortran 77 when it came out (and were ecstatic about thinks like CHARACTER variables) will take up the new syntax as fast as they can and drop Fortran 77 as fast as they dropped Fortran 66. 3) Those who prefer to keep puttering along with "simple" languages like Fortran 66 (gosh, wasn't dealing with character data in this very "simple" revision of the language fun?) and deliberatly refused to bother to learn Fortran 77 constructs will keep on writing in whatever they first learned. We have several people here like that- they are still annoyed when I use CHARACTER variables and those horrid IF () ... ENDIF clauses instead of nice neat GOTO's. Indentation of code is also a radical and frightening idea to these people. Before Fortran 77 came out, the compilers here had implemented about 3/4 of the constructs already. Some of the stuff in the 88 standard has been implemented in vendor-specific constructs already. Looking at just the Cray and CDC Fortran compilers and all of their high-performance additions to the language would seem to indicate that if we don't come up with a standard SOON for some of these constructs we are going to end up with a LOT of Fortran 77 code that can only run on one vendors machines. We already have about 110,000 lines of such code - we had to use the vendor specific syntax in order to get the programs to run in a reasonable amount of time. Now we can't share these programs with Cray users, since they use a different syntax. Kind of makes one wish that certain companies had gotten together and come up with a standard a few years back. I shudder to think what it costs to port our programs to the VAXens and Crays used by most of our collegues. I don't like everything in Fortran 88, but there is a lot more that I want to use VERY badly. So I say, forget about the people who are unwilling to add useful constructs to the language. In most cases, no matter what the constructs are, they won't want to learn them and would prefer to stay with whatever they learned in the first place. Fine. They don't have to use 'em. Alas, the same people who whined about having to open a book or ask someone what an IF () ... ENDIF construct was when Fortran 77 came out will be singing the same song when Fortran 88 comes out and they encounter someone elses code who decided that they were really neat. C'est la vie... -- Greg Kamer - Purdue Macromolecular Crystallography tsh@mace.cc.purdue.edu (internet - read every day) xtsh@purccvm.bitnet (bitnet - read very rarely)