ldl6737@rouge.usl.edu (Lafleur L Dwynn) (05/25/91)
Most of us physicists, mathematicians, and engineers educated in the '60s and '70s cut our programming teeth on mainframe computers using FORTRAN. Many have since moved from mainframes to personal computers and have found that there are other languages much more convenient for the PC platform, especially those which come packaged in a friendly, efficient programming environment (e.g., QuickBASIC or Turbo Pascal). Also, manufacturers of circuit boards that interface PCs to laboratory instrumentation (e.g., the Hewlett-Packard HPIB interface card) tend to write the interface software in these newer "PC languages", but not in FORTRAN. Some schools of engineering are, in fact, replacing FORTRAN with others as the language of choice. Now, I for one find it very difficult to program almost daily in two different languages. Maybe that's a sign of age, but I suspect most scientists would prefer to stick to just one language if they could. Putting aside the question of the effort involved, why don't most of us leave FORTRAN for one of the newer languages? In discussions with others, I seem to find two primary reasons for sticking to FORTRAN: (1) there exists a large stockpile of numerical subroutines and packages written over the decades, and (2) many of us do computation involving expressions with lots of operations on and functions of complex variables, a variable type not allowed in binary operations in such languages as BASIC, Pascal, and C. If you are a big user of existing FORTRAN software packages, the first of these reasons is sufficient for staying with FORTRAN and the question is decided. However, the second reason is beginning to erode. The recent appearance of C++ and other object oriented languages gives the programmer the use of complex operations with the almost the same ease as in FORTRAN. In fact, I understand the rather popular Turbo C++ includes a library defining essentially all the complex operations and functions appearing in FORTRAN. I am posting this message to stimulate an exchange of opinions between FORTRAN users about the advisability and experiences of switching to other languages. What do you think? L. Dwynn Lafleur Professor of Physics University of Southwestern Louisiana lafleur@usl.edu
rfinch@caldwr.water.ca.gov (Ralph Finch) (05/26/91)
I hope this doesn't deteriorate into another argument about: Fortran stinks; no it doesn't; yes it does; etc. Well here goes anyway. First of all, I think it's quite possible to know and use 2 or 3 languages. Around here we use Fortran, shell scripts, awk, and IDL pretty often. Each has their place, and what's easy to do in one is difficult in the other. Rather than junk Fortran for the latest new-fangled language, I would much rather see Fortran updated more frequently, at least once every 5 years. -- Ralph Finch 916-445-0088 rfinch@water.ca.gov ...ucbvax!ucdavis!caldwr!rfinch Any opinions expressed are my own; they do not represent the DWR
john@spectre.unm.edu (John Prentice) (05/26/91)
In article <31746@rouge.usl.edu> ldl6737@rouge.usl.edu (Lafleur L Dwynn) writes: > >I am posting this message to stimulate an exchange of opinions between FORTRAN >users about the advisability and experiences of switching to other languages. >What do you think? > There are lots of valid arguments pro and con concerning Fortran, but I think if you want to perfectly honest about it, the main reason scientists don't switch from Fortran is twofold. First, most scientists know virtually nothing about computers (though alot talk a great line). So they use what they have been led to believe is the language of scientists, namely Fortran. For those few who seem to actually know more about computers than just how to use the mail utility, I think alot of them stay with Fortran because their needs are simple and Fortran suits them fine. For the minority who are doing serious computational science, there is considerable ferment over whether Fortran is now or will the future be the language to use. But those people doing really serious work with computers are a minority, at least in physics (mind you, I am talking about people >really< doing work, not the many who talk about it but actually no next to nothing other than the jargon). None of this says anything about whether Fortran is a good or a bad language, it says loads about scientists however. John -- John K. Prentice john@unmfys.unm.edu (Internet) Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA
vsnyder@jato.jpl.nasa.gov (Van Snyder) (05/30/91)
In article <31746@rouge.usl.edu> ldl6737@rouge.usl.edu (Lafleur L Dwynn) writes: >Most of us physicists, mathematicians, and engineers educated in the '60s and >'70s cut our programming teeth on mainframe computers using FORTRAN. Many have >since moved from mainframes to personal computers and have found that there are >other languages much more convenient for the PC platform, especially those which >come packaged in a friendly, efficient programming environment (e.g., QuickBASIC >or Turbo Pascal). Also, manufacturers of circuit boards that interface PCs to >laboratory instrumentation (e.g., the Hewlett-Packard HPIB interface card) tend >to write the interface software in these newer "PC languages", but not in >FORTRAN. Some schools of engineering are, in fact, replacing FORTRAN with >others as the language of choice. > >Now, I for one find it very difficult to program almost daily in two different >languages. Maybe that's a sign of age, but I suspect most scientists would >prefer to stick to just one language if they could. Putting aside the question >of the effort involved, why don't most of us leave FORTRAN for one of the newer >languages? In discussions with others, I seem to find two primary reasons for >sticking to FORTRAN: (1) there exists a large stockpile of numerical subroutines >and packages written over the decades, and (2) many of us do computation >involving expressions with lots of operations on and functions of complex >variables, a variable type not allowed in binary operations in such languages as >BASIC, Pascal, and C. > >If you are a big user of existing FORTRAN software packages, the first of these >reasons is sufficient for staying with FORTRAN and the question is decided. >However, the second reason is beginning to erode. The recent appearance of C++ >and other object oriented languages gives the programmer the use of complex >operations with the almost the same ease as in FORTRAN. In fact, I understand >the rather popular Turbo C++ includes a library defining essentially all the >complex operations and functions appearing in FORTRAN. > >I am posting this message to stimulate an exchange of opinions between FORTRAN >users about the advisability and experiences of switching to other languages. >What do you think? > > >L. Dwynn Lafleur >Professor of Physics >University of Southwestern Louisiana >lafleur@usl.edu When the Fortran 77 standard was promulgated, Fortran was the only standardized and widely available language that got arrays right. Pascal still doesn't allow open arrays. Modula-2 allows open arrays of one dimension. PL\I and Ada aren't widely available. Arrays in C are a bogus pointer manipulation that has a few quirks that make arrays not quite right. Fortran 90 improves on Fortran 77 arrays by making whole arrays and array sections first class objects. And now machine inquiry is standardized as well. There are lots of things in Fortran 90 that I would have done differently (mostly more regularly), but on the whole, nothing compares yet for numerical work. -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp
jlg@cochiti.lanl.gov (Jim Giles) (05/30/91)
In article <1991May29.205700.27104@jato.jpl.nasa.gov>, vsnyder@jato.jpl.nasa.gov (Van Snyder) writes: |> |> Fortran 90 improves on Fortran 77 arrays by making whole arrays and array |> sections first class objects. And now machine inquiry is standardized as well. |> |> There are lots of things in Fortran 90 that I would have done differently |> (mostly more regularly), but on the whole, nothing compares yet for numerical |> work. Well, there is, but I doubt it will ever be implemented. There was some talk about revising the standard more often (like every 5 years) in the last couple of weeks. Well, 5 years from Fortran 77 (1982) a document was published by the DOE called the LWG Fortran Manual. It was the result of the DOE Language Working Group effort to propose useful extensions to Fortran 77. The committee was small and exclusive with representatives from only the 8 DOE labs. In every respect, the LWG Fortran proposal is superior to the Fortran 90 proposed standard. Not only does it beat Fortran 90 on a feature by feature basis, it also has the obvious features that Fortran 90 left out: variant records, recursive data types, asynchronous I/O, BIT type, Cray style pointers, conditional compilation, macros, and compiler directives for listing and optimizataion control. And yes, it also has machine inquiry functions. There are things in the LWG document I would have done differently if it were solely up to me. But, I would support it as a proposed standard and I oppose the Fortran 90 proposal (which is a decade later and not as good). J. Giles
sjc@borland.com (Steve Correll) (05/31/91)
Prof. Lafleur asks an interesting question: essentially, "If you had to write a numerical application entirely from scratch, would you use Fortran or C++?" I wouldn't use Pascal, C, or Modula-2, because each has at least one of these defects: 1. Can't declare a true multidimensional array with arbitrary lower bounds. 2. Can't reshape an array by passing it as an actual argument, or design a single function to operate automatically on arrays of varying shape. 3. Can't use intrinsic functions and operators on doubleprecision and complex data. 4. Can't control the precision and order of evaluation of arithmetic expressions. The good news? C++ can do all of these. Examples in Stroustrup's book provide a starting point for (1) and (2); as noted, Borland C++ provides a library for (3) (actually, it's for doublecomplex, but complex is an easy extension). Fortran remains much more convenient with regard to (4). Whereas Fortran says "parentheses are sacrosanct", C++ permits the compiler to use arithmetic identities which create or destroy parentheses, so the user may need to break an expression into multiple assignment statements to prevent reordering. Fortran 90 has raised the goalposts somewhat by adding dynamic allocation, array sectioning, and intrinsic functions and operators on arrays, but these are all clearly possible with C++: somebody just has to spend time writing class libraries to implement them. So what's the bad news? The C++ compiler has a tougher time generating efficient code, because it knows less about the program. For example, confront a hypothetical Fortran 90 compiler with a statically indexed array copy: X(1:10) = X(11:20) + X(21:30) It can observe at compilation time that the source and target are disjoint and emit special-case code that avoids using an intermediate temporary array. The C++ compiler sees a bunch of operators overloaded with library functions which were written to handle the general case, where copying is required. If the author of the functions was careful, s/he tests the source and target for disjoint-ness and branches to special-case code which avoids the temporary--but that test occurs at execution time, every time you invoke the operation. (Other examples involving dynamically indexed arrays are equally problematical for both compilers, of course.) In time, I expect the best C++ implementations will inline the function calls, analyze the dependencies, eliminate the test, discard the unreachable code, and thus generate the same code as our hypothetical Fortran 90 compiler does in the special case (and better code in the general case, unless the Fortran 90 compiler adopts similar optimizations). But the C++ implementor must solve a bunch of general problems in optimization (a lot of work, at the end of which everything runs faster) whereas the Fortran 90 implementor can use heuristics to optimize specific common cases (only the common cases improve, but you can deliver sooner). A rash prediction: early Fortran 90 compilers will be so lousy that the best current C++ implementations with carefully written class libraries would beat them at execution time. Later Fortran 90 compilers will step ahead via heuristics. Then C++ will catch up by implementing more sophisticated general optimizations sooner (Fortran 90 compilers are handicapped by a late start, and will spend a lot of time shaking out semantics-versus-optimizer bugs due to their complicated source language). In the long run, if Fortran 90 is popular, its compilers should come out ahead in performance both because some things just aren't visible to C++ at compilation time, and because the Fortran market values numerical performance more highly than the C++ market does.
fitz@mml0.meche.rpi.edu (Brian Fitzgerald) (06/02/91)
Lafleur L Dwynn writes: >Some schools of engineering are, in fact, replacing FORTRAN with >others as the language of choice. Why would a dean of engineering declare a language of choice? :-) Brian
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (06/04/91)
In article <a=rhbw+@rpi.edu>, fitz@mml0.meche.rpi.edu (Brian Fitzgerald) writes: >Lafleur L Dwynn writes: > >>Some schools of engineering are, in fact, replacing FORTRAN with >>others as the language of choice. > >Why would a dean of engineering declare a language of choice? :-) > >Brian Indeed! And while in the process of forcing a "language of choice" on the students, why would they settle on "others" to be this language? This must certainly be a generic school! I would go there if I could -- the answer to every exam question would be "none of the above". It would be hard to get a job, though, if you had to write "other" or "not applicable" to indicate your major or specialization. Of course, it might be impressive to put "varying" for "degrees". "salary expectation" could be made more specific, with "certainly". -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "not much better than CANADA | datclaimer" -------------------+-------------------------------------------