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

  1. Xref: sparky comp.edu:1403 comp.lang.fortran:3271 comp.lang.misc:2798 sci.math:10684
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!rutgers!network.ucsd.edu!lyapunov.ucsd.edu!mbk
  3. From: mbk@lyapunov.ucsd.edu (Matt Kennel)
  4. Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,sci.math
  5. Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
  6. Message-ID: <17mcr4INN4qq@network.ucsd.edu>
  7. Date: 28 Aug 92 23:28:36 GMT
  8. References: <BtpAIn.EE5@mentor.cc.purdue.edu>
  9. Organization: Institute For Nonlinear Science, UCSD
  10. Lines: 109
  11. NNTP-Posting-Host: lyapunov.ucsd.edu
  12. X-Newsreader: Tin 1.1 PL3
  13.  
  14. hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  15. : The problem is that the CS people are, in this sense, like the purissima
  16. : mathematicians (if it can be applied, it is time to work on something else.)
  17. : They concentrate on what no scientist is particularly worried about, like
  18. : making the printed output look neat, or even making life easy for the
  19. : compiler.
  20.  
  21.  
  22. : Most good scientists can think of their problem, and how reasonable operations
  23. : can attack it.  But the languages do not facilitate this, and often even if 
  24. : the features are present, they are in some obfuscated syntax.
  25.  
  26. I agree.  I believe the CS vs. Science programming divide is cultural, but
  27. I'm going be somewhat partisan and blame the programming authorities a bit more
  28. than the scientists.
  29.  
  30. My view of things:
  31.  
  32. 1) There are scientists who don't know the value of organized software
  33.     engineering.  I mean basic things like type-checking subroutine
  34.     arguments, modularization, modern data types, and other things like
  35.     that.  They write the infamous spaghetti Fortran.
  36.  
  37. 2)  There are computer scientists who don't understand the demands of
  38.     scientific computing, which is understandable, because they never
  39.     write scientific programs.
  40.  
  41. The problem is this:
  42.  
  43. There are scientists who *have* learned the value of good software
  44. engineering and believe what the comptuer scientists have said for years, and
  45. honestly try to stay up to date.
  46.  
  47. Too many CSoids however dismiss the concerns of scientists as being
  48. narrow and "uninformed", assuming that they're all like the nerds in
  49. #1 above.  Or they claim that language X does what scientists need
  50. (or "no we don't need to bother because it's possible to implement that
  51. in a library" or "a quality of implementation issue" (a euphemism for
  52. "we don't really give a shit") ) and say that we're silly when we disagree.
  53.  
  54. Software technology and practice for addressing the particular concerns of
  55. computer scientists has advanced tremendously since the early days, but the
  56. model of scientific computation hasn't changed much since early Fortran
  57. except vicariously through the progress in "regular" computer science.
  58.  
  59. I personally would love a "Numerical Eiffel" type of language, but I bet the
  60. Eiffel gurus would say "eeuy yuck, you're polluting our pristine creation
  61. with needless cruft".  One of the Modula-3 people has said that one of
  62. their design goals was to make it good for numerical computation (a
  63. refreshing attitude).  One of the examples was "easy access to the IEEE
  64. rounding modes" (what the f*???) as standard in the library, but admitted that
  65. complex numbers weren't, much less array operations.
  66.  
  67. I don't want "good for numerical computation" to mean "not all that much
  68. worse than Fortran 77"!
  69.  
  70. I believe Herman Rubin and other mathemeticians when they say that they want
  71. good performance and easy use of multiprecision integers and fixed point
  72. numbers, even though I and most physicists, would never have a use for
  73. them.  So can the computer scientists accept our needs as well?  Remember,
  74. it's the scientific programmers who *DO* want change who are doing all the
  75. complaining--the "old farts" just keep on banging out Fortran and mind their
  76. own business.
  77.  
  78. Scientists don't want to needlessly accept *regress* in concrete areas in
  79. order to make supposed "progress" in areas they haven't been convinced they
  80. want.  The progress has to be good enough to convince departmental computer
  81. comittees to buy a new $2000 compiler.  Notice that scientists aren't
  82. all that hidebound by tradition---they enthusiastically take up Maple
  83. and Mathematica---because they can immediately recognize progress, and
  84. even despite their lack of "goto". :-)
  85.  
  86. And finally the old standby "why speed is in fact, important".  Why does
  87. factor of 2 matter?  It's the old "the program is everything" view.  Running
  88. any particular one program faster is not, in fact, what matters.  What does
  89. matter, is that with a faster machine and a faster language I can do *more*
  90. and *better* science.  (I could easily use up a 10 teraflop machine next
  91. month.) Many times we're running things on hardware far too underpowered to
  92. "do the job right" in any case, but science accepts approximate solutions.
  93.  
  94. Take the statement, "Scientific progress is proportional to the logarithm of
  95. computer power."
  96.  
  97. The computer scientist hears this and says "You silly fools, if you
  98. saw the big picture you'd realize that the constant factor doesn't matter
  99. one bit so quit complaining."
  100.  
  101. The scientist hears this and says "Well that's why we need to get
  102. all we can get, and then some, in order to make progress."
  103.  
  104.  
  105. I think there is in fact some hope.
  106.  
  107. Specifically, the parallel- and super- computer research community.
  108. In it, there are people who truly understand both the computer scientists
  109. and the scientific users and are committed to progress rather than
  110. defining away the problem as uninteresting or trivial.
  111.  
  112. : -- 
  113. : Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  114. : Phone: (317)494-6054
  115. : hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  116. : {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  117.  
  118. --
  119. -Matt Kennel          mbk@inls1.ucsd.edu
  120. -Institute for Nonlinear Science, University of California, San Diego
  121. -*** AD: Archive for nonlinear dynamics papers & programs: FTP to
  122. -***     lyapunov.ucsd.edu, username "anonymous".
  123.