home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / edu / 1368 < prev    next >
Encoding:
Internet Message Format  |  1992-08-31  |  2.9 KB
  1. Xref: sparky comp.edu:1368 comp.lang.fortran:3205
  2. Newsgroups: comp.edu,comp.lang.fortran
  3. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  4. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  5. Subject: Re: Modern languages: F90, C++, etc... (Was: scientists as programmers)
  6. Message-ID: <9224015.18703@mulga.cs.mu.OZ.AU>
  7. Sender: news@cs.mu.OZ.AU
  8. Organization: Computer Science, University of Melbourne, Australia
  9. References: <l9lrciINNb7b@almaak.usc.edu> <h=bnn6@lynx.unm.edu> <9224001.1511@mulga.cs.mu.OZ.AU> <szbnn0l@lynx.unm.edu>
  10. Date: Thu, 27 Aug 1992 05:11:37 GMT
  11. Lines: 52
  12.  
  13. john@aquarius.unm.edu (John Prentice) writes:
  14.  
  15. >I think a more interesting issue is not C++ versus F90, if one wants
  16. >to frame it as a versus sort of issue, but rather the general idea 
  17. >of OOPS versus conventional languages.
  18.  
  19. Actually I think that C++ would be a good language to use even if you
  20. *didn't* use any of the OOP features, ie. just using C++ as a better C.
  21. Just grab M++ or some other class library off-the-shelf and then
  22. use C++ like a conventional language.
  23.  
  24. Then the extra features of C++ are available if you need them.
  25.  
  26. >I happen to think there is alot of merit in OOPS and I think it has an
  27. >unquestioned place in scientific computing.  However, I also think it
  28. >is overhyped very often.
  29.  
  30. Yes, any new techniques in computer science are ALWAYS over-hyped.
  31. OOP is not a panacea that will suddenly make programming complex systems
  32. easy. However it *is* a significant improvement in the same way that
  33. structured programming was a significant improvement over previous methods.
  34.  
  35. >For example, one of the common claims for OOPS being the method
  36. >of choice for parallel computing is that you can easily hide the 
  37. >underlying machine architecture from the programmer.  This is said
  38. >to be good because it relieves the programmer of having to worry about
  39. >that architecture and promotes portability.
  40.  
  41. If these are your goals, then it is can be good for these purposes.
  42.  
  43. >The problem is that it
  44. >also promotes code inefficiency since the programmer, who understands
  45. >the data and logic structure of his code very well, is not able to
  46. >direct the computer to exploit that structure as efficiently if he
  47. >can't get to the underlying parallelization software.  The idea of
  48. >hiding the nature of the computer from the programmer is not a bad
  49. >one for users doing small computing, but it is not acceptable when each
  50. >of your calculations takes 50 hours of Cray Y-MP or CM time.
  51.  
  52. If minimizing machine cycles is your goal, then of course programmers
  53. will have to program at a lower level.
  54.  
  55. >So it is not that OOPS is bad, it is just that like everything, it has
  56. >a time and a place.
  57.  
  58. Absolutely.
  59.  
  60. -- 
  61. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  62. This .signature virus is a self-referential statement that is true - but 
  63. you will only be able to consistently believe it if you copy it to your own
  64. .signature file!
  65.