johnson@cs.uiuc.edu (Ralph Johnson) (12/21/90)
I found the paper by Pancake and Bergmark interesting, too. One thing that I did NOT like was their assumption that Fortran was the only way to go. Fortran is a horrible language. It has very good implementations, it is true. Scientific computation would progress a lot faster if people managed to get away from Fortran. Of course, I have no immediate candidates to replace Fortran for scientific computation. A lot of scientists around here are fans of Mathematica, and claim that it is very well suited to scientific computation. Of course, like all new languages, Mathematica is pretty slow. It seems to take a long time for people to make new languages as fast as old ones. Fortran's domination of the scientific programming marketplace seems to have stifled the development of competitors.
eugene@nas.nasa.gov (Eugene N. Miya) (12/27/90)
Doug Pase, Doreen Cheng and I just hashed over some of the topics of this paper for 2 hours. We went down line by line of their table. On the table typo: I believe the examples "critical section and barriers" appeared on the wrong side and should be swapped for "routine calls." In article <12382@hubcap.clemson.edu> johnson@cs.uiuc.edu (Ralph Johnson) writes: >One thing that I did NOT like was their assumption that >Fortran was the only way to go. Fortran is a horrible >language. It has very good implementations, it is true. >Scientific computation would progress a lot faster if >people managed to get away from Fortran. Please do not blame the bear of "bad news." In fact I think you will find a lot of people wondering why you think it's horrible. Pancake and Bergmark described the situation, well, in my opinion. I did not detect a particular bias, just a reporting of the situation. Other languages in common scientific use include BASIC (for better or worse), Pascal as well as C for PCs. I think C predominated because of Unix as a first OS and found in graphics packages (P&B's note on other languages). Several parts of the problem: the horrors "evident" to computer scientists such as "GOTO considered harmful," the values of user-defined structures and types are not apparent to scientific programmer/computational scientists. We have a real education problem here. Education takes valuable time and money. It also uses scientific personnel resources. These structures (like GOTOs) are not problems in the small. They are problems "in the large." That's what makes them deceptive problems. Every one must face that science has amassed knowledge in the form of these programs (big programs). Changing them is non-trivial. Our users want to solve their problems, not computer science's problems. We need some give and take. >Of course, I have no immediate candidates to replace >Fortran for scientific computation. A lot of scientists >around here are fans of Mathematica, and claim that it >is very well suited to scientific computation. Of course, >like all new languages, Mathematica is pretty slow. It >seems to take a long time for people to make new languages >as fast as old ones. Fortran's domination of the scientific >programming marketplace seems to have stifled the development >of competitors. I can think of languages I would find interesting, but it takes the accumulated experience of a user community to find problems with a language. It's an art. I'd like to see more work with SISAL, a dataflow language. I know people who would like LISP variants like *LISP and Scheme, and I can't convince one physicist the value of LISP, yet he just wrote an FFT in awk (and uses yacc and lex for physics problems, so not your average physicist). I've had many discussions with many end-users and they wonder why computer scientists 1) dump on Fortran, 2) propose new languages, etc. Why not add features to existing languages? (it's hard for some of them to understand syntax versus semantic difference; one doesn't compare languages simply by counting KEYWORDS.) It has also been said Ada has set back programming language development back ten years, and Unix has set operating system development back as well. Our problem is that it takes time to identify problems. What is slow about Mathematica is not the language by the implementation. I would have added a couple of other observations Scientific programmers seem to run more on IBM PCs, Macs, and SGI Iris whereas more computer scientists run on SUNs. A real workstation preference (with a smattering of H-P, and other machines). Goes with cost and graphics. I would also add that Pancake and Bergmark should read Knuth's article on Algorithmic versus Mathematical Thinking, American Math Monthly, March or April 1985. Doug Pase noted that parallelism is a concern everywhere but the abstract math modeling phase of P&B's hierarchy. So the paper is a good spring board for discussion. --e. nobuo miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov {uunet,mailrus,other gateways}!ames!eugene