home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / edu / 1360 < prev    next >
Encoding:
Internet Message Format  |  1992-08-30  |  5.4 KB

  1. Xref: sparky comp.edu:1360 comp.lang.fortran:3198
  2. Newsgroups: comp.edu,comp.lang.fortran
  3. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!caen!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!lynx!aquarius.unm.edu!john
  4. From: john@aquarius.unm.edu (John Prentice)
  5. Subject: Modern languages: F90, C++, etc... (Was:scientists as programmers)
  6. Message-ID: <szbnn0l@lynx.unm.edu>
  7. Date: Wed, 26 Aug 92 18:59:15 GMT
  8. Organization: Dept. of Physics & Astro, University of New Mexico, Albuquerque
  9. References: <l9lrciINNb7b@almaak.usc.edu> <h=bnn6@lynx.unm.edu> <9224001.1511@mulga.cs.mu.OZ.AU>
  10. Lines: 86
  11.  
  12. In article <9224001.1511@mulga.cs.mu.OZ.AU> fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  13. >john@spectre.unm.edu (John Prentice) writes:
  14. >
  15. >>My final comment is my stock one about Fortran.  Continuing to
  16. >>debate the pros or cons of Fortran 77 is a cheap shot, not worthy
  17. >>of serious discussion.  Fortran 77 is out of date, everyone agrees
  18. >>with that.  Fortran 90 is a modern language, with certainly as much
  19. >>claim to that title as languages like C.  You can argue the merits
  20. >>of some of what is in Fortran 90, and I would welcome such a
  21. >>discussion.  But at least we would then be debating where the
  22. >>scientific programming community is today, not where it was 20
  23. >>years ago.
  24. >
  25. >Continuing to debate the pros or cons of C is a cheap shot, not worthy
  26. >of serious discussion. C is out of date, everyone agrees with that.
  27. >C++ is a modern language, with certainly MORE claim to that title
  28. >than languages like Fortran, even Fortran 90. You can argue about
  29. >the relative merits of C++ vs Fortran 90, and I would welcome such a
  30. >discussion. But at least we would then be debating the languages of 
  31. >today, not those of 20 years ago.
  32. >
  33. >:-) :-) :-)
  34.  
  35. I think a more interesting issue is not C++ versus F90, if one wants
  36. to frame it as a versus sort of issue, but rather the general idea 
  37. of OOPS versus conventional languages.  I happen to think there is
  38. alot of merit in OOPS and I think it has an unquestioned place in
  39. scientific computing.  However, I also think it is overhyped very
  40. often.  For example, one of the common claims for OOPS being the method
  41. of choice for parallel computing is that you can easily hide the 
  42. underlying machine architecture from the programmer.  This is said
  43. to be good because it relieves the programmer of having to worry about
  44. that architecture and promotes portability.  The problem is that it
  45. also promotes code inefficiency since the programmer, who understands
  46. the data and logic structure of his code very well, is not able to
  47. direct the computer to exploit that structure as efficiently if he
  48. can't get to the underlying parallelization software.  The idea of
  49. hiding the nature of the computer from the programmer is not a bad
  50. one for users doing small computing, but it is not acceptable when each
  51. of your calculations takes 50 hours of Cray Y-MP or CM time.  So
  52. it is not that OOPS is bad, it is just that like everything, it has
  53. a time and a place.
  54.  
  55. I would take the argument away from one over specific implementations
  56. of these language ideas however.  One reason is that as soon as you
  57. start talking about C++, you are going to get jumped on by real OOPS
  58. purists who will tell you that C++ is nothing but some OOPS ideas
  59. layered on top of a bad conventional language (and they are arguably
  60. correct).  A real purist would insist on something like SmallTalk,
  61. not C++.  The pros and cons of that argument aside, the point is that
  62. there *are* some very important issues for scientific computing with
  63. regard to the use of OOPS and we should be thinking about them, not
  64. about language wars.
  65.  
  66. While we are at it, we should be talking about functional languages
  67. also.  Their potential for applicability to scientific computing is
  68. certainly as great as OOPS and possibily much greater.  So, if people
  69. would like to engage in a discussion of conventional versus OOPS
  70. versus functional, I would find it valuable and fascinating.
  71.  
  72. As for Fortran 90, X3J3 did a good job of producing a modern dialect
  73. of Fortran which compares well with every other conventional programming 
  74. language.  But unlike virtually every other language out there, Fortran 
  75. is an evolving language.  Fortran 77 was a major change from Fortran 66,
  76. with new programming ideas incorporated into it.  Fortran 90 is an even
  77. more radical evolution.  Work is now going on for the next version of
  78. Fortran and what goes into it will be a function of what the user
  79. community demands.  Certainly, I would expect Fortran xx to encorporate
  80. support of data parallelizm, perhaps control parallelism, and who knows,
  81. perhaps even OOPS.   What other language is making those kinds of
  82. evolutionary strides, and doing so in the context of international standards
  83. which preserve code portability across large numbers of computers?
  84. The ANSI version of C, for example, did nothing more than clean up some of 
  85. the worst deficiencies of the original C, it introduced very little that 
  86. was new.  So my point is, you can trash on Fortran for not being a
  87. forefront language, and you would be largely correct.  But you also 
  88. have to give it great credit for being the most dynamic of the major
  89. languages (by which I mean languages in which people actually write large
  90. programs), one which is contuously improving and evolving.
  91.  
  92. John
  93. -- 
  94. Dr. John K. Prentice                      
  95. Partner, Quetzal Computational Associates    
  96. 3200 Carlisle N.E., Albuquerque, NM   87110-1664; 505-889-4543
  97. john@aquarius.unm.edu -or- jkprent@cs.sandia.gov -or- prentice@rufous.cs.unm.edu
  98.