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

  1. Xref: sparky comp.edu:1531 comp.lang.fortran:3426 comp.lang.misc:2932 comp.arch:9223 sci.math:10989
  2. Path: sparky!uunet!decwrl!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  3. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  4. Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
  5. Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
  6. Message-ID: <Bu255r.6tD@mentor.cc.purdue.edu>
  7. Date: 4 Sep 92 14:20:14 GMT
  8. References: <1992Sep1.173636.6387@nntpd.lkg.dec.com> <1992Sep2.133810.24957@newsroom.bsc.no> <ARI.HUTTUNEN.92Sep4011522@supergirl.hut.fi>
  9. Sender: news@mentor.cc.purdue.edu (USENET News)
  10. Organization: Purdue University Statistics Department
  11. Lines: 55
  12.  
  13. In article <ARI.HUTTUNEN.92Sep4011522@supergirl.hut.fi> Ari.Huttunen@hut.fi (Ari Juhani Huttunen) writes:
  14. >In article <1992Sep2.133810.24957@newsroom.bsc.no> izahi@bsc.no (Raul Izahi Lopez Hernandez) writes:
  15.  
  16. >!    A good compiler and a good optimizer can help any scientist to write
  17. >! reasonable code, however there is no software yet that can help a CS
  18. >! person write any physics code.
  19.  
  20. >What do you mean by 'reasonable code'? Do you mean code that solves correctly
  21. >the test problems that were available when the code was written? Or do you
  22. >mean code that solves _any_ problem it was intended to solve, regardless
  23. >how different the actual problem is from the original test data?
  24.  
  25. >If the former is what you mean by 'reasonable code', then go ahead and
  26. >use untrained programmers and rely on the compiler and optimizer to
  27. >do the job. (NOTE that I did not write 'physicist' in that sentence.)
  28. >If the latter is your concern and you want correct solutions, use 
  29. >a professional!
  30.  
  31. >To produce first quality code, the best solution would in my view
  32. >be to use 1) a physicist 2) a computer science person, paired up in
  33. >a team. Both should know something of the other's profession. Neither
  34. >is sufficient alone. Of course, a person that can do both would be
  35. >better, but being mere mortals, such persons are difficult to find.
  36.  
  37. This is exactly what we should have been doing all along.  There seems
  38. to be a tendency everywhere to try to either break up a task (like 
  39. having one doctor treat the heart, and another the lungs, and never
  40. having them communicate; or having the physicist write the formulas,
  41. and the programmer try to program them, without the programmer having
  42. any idea even of typical values), or to set things up so that a single
  43. individual "should" be able to do it alone, like setting up packages
  44. which SUPPOSEDLY do the statistical procedures which any social
  45. scientist should want to use.  Both of these necessarily fail.
  46.  
  47. Now most universities provide statistical consulting.  One of the
  48. big problems is to convince the user that it is not enough to dump
  49. the data on the consultants desk (or to give the consultant a tape
  50. or a disk) and expect the proper thing to be done.  There have been
  51. postings on many groups asking to "fit a curve" to data.  Now I do
  52. not know which of the many versions of this a client means without
  53. questioning the client.  The biggest problem, in practice, is that
  54. the client does not know what is wanted.
  55.  
  56. It is also the case that mathematicians in universities will often 
  57. provide help.  But nothing like this is available at the programming
  58. level; there is no problem in getting government support for faculty
  59. to program their own jobs, but not for paying graduate students to 
  60. work with them on research which cannot be used in doctoral dissertations. 
  61. The consulting facilities provided by computing centers do not extend to
  62. helping with programming.
  63. -- 
  64. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  65. Phone: (317)494-6054
  66. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  67. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  68.