home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / fortran / 3226 < prev    next >
Encoding:
Text File  |  1992-08-27  |  3.3 KB  |  71 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!gatech!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!laphroaig!cflatter
  3. From: cflatter@nrao.edu (Chris Flatters)
  4. Subject: Re: Scientists as Programmers (was Re: Small La
  5. Message-ID: <1992Aug27.155835.27972@nrao.edu>
  6. Sender: news@nrao.edu
  7. Reply-To: cflatter@nrao.edu
  8. Organization: NRAO
  9. References: <1992Aug26.192410.6523@ultb.isc.rit.edu>
  10. Date: Thu, 27 Aug 1992 15:58:35 GMT
  11. Lines: 58
  12.  
  13.  
  14. In article 6523@ultb.isc.rit.edu, jsvrc@rc.rit.edu (Doctor FORTRAN) writes:
  15. >In article <1992Aug25.154501.8654@colorado.edu> ejh@khonshu.colorado.edu (Edward J. Hartnett) writes:
  16. >
  17. >> [. . . . ] I think that
  18. >>what you are seeing is not that FORTRAN lends itself to rotten code,
  19. >>but that scientists usually write bad code, in whatever language they
  20. >>use. No offense to scientists, but I have rarely if ever seen a
  21. >>scientist who was a good programmer.
  22. >
  23. >Then you haven't met Dr. FORTRAN. :-) Seriously, there are scientists who
  24. >write good code, and there are those who write bad code. Going by my personal
  25. >experience, I would imagine that at least some of the scientists who write
  26. >good code have in the past written bad code that came back to haunt them.
  27. >
  28. >Nevertheless, you do have a point. Software specialists will argue about the
  29. >best data structure to use for a problem, and still be trying to dope it out
  30. >while the scientist has the whole thing already coded. That's because the
  31. >scientist will see the program as what it truly is: a means to an end, rather
  32. >than as an end unto itself. If computing is an end unto itself, it cannot
  33. >be of practical consequence. (Didn't Hamming like to say that the purpose of
  34. >computing was insight, not numbers?) But I must disagree when you characterize
  35. >scientists as bad programmers. That's bigotry, and a stereotype to which I
  36. >must strenuously object.
  37. >
  38. >I thank you.
  39. >
  40. >Doctor FORTRAN
  41.  
  42.  
  43. In "The Psychology of Computer Programming" Gerald Weinberg divided
  44. programmers into two classes, professionals and amateurs (pp122-125).
  45. In his terms most scientists are amateur programmers (I would actually
  46. prefer to use the term casual programmers, which avoids the somewhat
  47. derogatory implications of amateurism).  They write programs mainly for
  48. their own use and often only for a limited number of runs while a
  49. professional writes programs that other people are expected to use.
  50.  
  51. The casual programmer can get a program up and running faster than a
  52. professional because he can avoid dealing with many issues of software
  53. quality: he doesn't expect to get people beating on his door to
  54. complain that an error message or that certain inputs caused his
  55. program to dump core.  A software specialist has to (or, perhaps more
  56. realistically, should) bother about the convenience of the user who
  57. will not know the internals of the program.  The casual programmer
  58. doesn't need to bother about this and may be somewhat bewildered at the
  59. time and effort software specialists spend planning a program before
  60. they write it.
  61.  
  62. This isn't intended to belittle casual programmers.  They have a different
  63. set of priorities from software specialists and so tend to work in different
  64. ways.  There is, however, a widespread problem in scientific computing:
  65. casual programmers are often dragooned into writing software for other
  66. people to use.  This is asking for trouble unless they are willing to
  67. change their programming habits.
  68.  
  69.     Chris Flatters
  70.     cflatter@nrao.edu 
  71.