phipps@garth.UUCP (Clay Phipps) (01/13/89)
In article <117400003@uxa.cso.uiuc.edu> gsg0384@uxa.cso.uiuc.edu writes: > > ... I think we, stone-age FORTRAN programmers, >usually physicists, mechanical engineers, and civil engineers, >need [dynamic *local* array sizing] desperately. >Otherwise, we should always provide the source code to the customer >so that he can redimension for the memory size of his hardware. >Too often I cannot help thinking that the CStists do research >on what they like to do, but not on what most users want them to do. >The result is that we still don't have a language any better than >FORTRAN 77 for our purpose, ... The net's Algol partisans have already posted their comments, I think. Workable solutions were supplied by a language designed initially under the name FORTRAN VI in the early 1960s. So many changes were made away from the Spirit of FORTRAN that the language was eventually renamed PL/I. It's still possible to find PL/I compilers laying around for many minis and mainframes. The language user community you identified chose to stick with FORTRAN, rather than switch to PL/I. Time on the order of a decade elapsed between the 1st release of PL/I and completion of the FORTRAN 77 standard. Ask the FORTRAN committee why the features you wanted aren't *already* a part of the language. If you want the Cray features on another machine, complain to your computer's manufacturer's marketing and sales organizations. Computer manufacturers depend heavily on their marketeers to decide, *in effect*, what extensions and features, *if any*, their compiler folks will provide in later releases of their compilers. Compiler people can talk until they are blue in the face to management about the features they think are "needed" in an existing compiler, but until some potential customer waves big bucks in front of sales people ("no feature, no sale"), those "needed" features often just won't happen. [It may not be this way where I now work, but it was at other companies.] A favorite "feature" of customers, marketing, and sales alike, is *speed*. Compiler writers working to get the fastest compiler for the "next release" typically aren't spending time adding other features. Adding extensions to FORTRAN that duplicate features available in other well-known languages is not generally considered *computer science research*. Politics, maybe, but not research. -- [The foregoing may or may not represent the position, if any, of my employer] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps Intergraph APD, 2400#4 Geng Road, Palo Alto, CA 93403 415/494-8800
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (01/14/89)
In article <2401@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: > >Time on the order of a decade elapsed between the 1st release of PL/I >and completion of the FORTRAN 77 standard. Ask the FORTRAN committee >why the features you wanted aren't *already* a part of the language. Most vendors DO support dynamic memory in one way or another. Fortran 88 (the WG5 document, and the current ansi draft) has it as part of the evolved language. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
elg@killer.DALLAS.TX.US (Eric Green) (01/14/89)
in article <2401@garth.UUCP>, phipps@garth.UUCP (Clay Phipps) says: > In article <117400003@uxa.cso.uiuc.edu> gsg0384@uxa.cso.uiuc.edu writes: >> ... I think we, stone-age FORTRAN programmers, >>usually physicists, mechanical engineers, and civil engineers, >>need [dynamic *local* array sizing] desperately. >>... Too often I cannot help thinking that the CStists do research >>on what they like to do, but not on what most users want them to do. >>The result is that we still don't have a language any better than >>FORTRAN 77 for our purpose, ... > Workable solutions were supplied by a language designed > initially under the name FORTRAN VI in the early 1960s. > So many changes were made away from the Spirit of FORTRAN > that the language was eventually renamed PL/I. > It's still possible to find PL/I compilers laying around > for many minis and mainframes. The language user community you > identified chose to stick with FORTRAN, rather than switch to PL/I. A slight note for PL/1 advocates: PL/1 will do almost ANYTHING -- everything that Fortran will do, and everything that Cobol will do. And do it better, too. BUT, there's a side effect there: the language is HUGE. Until Ada, it was the largest language out there. The final effect is that the language is intimidating to learn, and difficult to build a compiler for. Compilers for it are either quite large and slow, or else generate lousy code. I have seen PL/1 compilers generate excellent code, as good as Fortran or whatever, but not without the compiler spending large amounts of space & time to do it. People who advocate PL/1 as a replacement for Fortran should be trying to sell dehumidifyers in Nevada. Re: lament of physicist types that there's no real replacement for Fortran: anybody have a counterexample? Anybody have a compiler which is as good for numerical work, and generates code as fast and efficient? PLUS, is small enough so not to intimidate the non-professional programmers? -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 Netter A: In Hell they run VMS. Netter B: No. In Hell, they run MS-DOS. And you only get 256k.
mccalpin@loligo.cc.fsu.edu (John McCalpin) (01/14/89)
In article <6779@killer.DALLAS.TX.US> elg@killer (Eric Green) writes: >Compilers for ...(PL/1)... are either quite >large and slow, or else generate lousy code. I have seen PL/1 >compilers generate excellent code, as good as Fortran or whatever, but >not without the compiler spending large amounts of space & time to do it. For large computations, I don't consider this to be a problem at all. It seems to me that this is one of the purposes of computers -- to spend large amounts of time and memory to make *my* job easier.... The only significant difficulty is that a compiler that strains my supercomputer is not likely to be very useful on my workstation, and a compiler that does not exist in both places is going to be an unused compiler.... This, IMHO, is the *principal* issue of languages in the supercomputer environment. We have a bunch of languages (Algol-68, vector Pascal/ Modula-2, vector C, vector Fortran [NOT 8X]) on our supercomputers (Cyber 205 and ETA-10), but without the *same* syntax and extensions on our VAXen or workstations, these languages are not ever going to be used. This is the promise of Fortran-8X, despite it's obvious flaws. >Re: lament of physicist types that there's no real replacement for >Fortran: anybody have a counterexample? Anybody have a compiler which >is as good for numerical work, and generates code as fast and >efficient? PLUS, is small enough so not to intimidate the >non-professional programmers? >-- >Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Speed and efficiency depend a great deal on the problem being solved. For my work (computational fluid dynamics and partial diferential equations), it is not difficult to write code that is nearly 100% long vectors. In that case, the scalar optimization of the language counts for little relative to the ability to cleanly specify the vector operations that I need done. So the vector extensions in the languages mentioned above all produce very similar performance. For non-vectorizable code or scalar hardware, then the compiler technology becomes much more important. I have not yet been convinced that these other languages are inherently less efficient than Fortran. I may take a bit more compile-time effort, but the same computational problem should be optimizable to very similar code in all cases. Of course, it is easier to write code which is hard to optimize in a more abstract language, but the user still needs *some* challenges.... -- ---------------------- John D. McCalpin ------------------------ Dept of Oceanography & Supercomputer Computations Research Institute mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu ------------------------------------------------------------------