home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / edu / 1351 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  3.1 KB
  1. Xref: sparky comp.edu:1351 comp.lang.fortran:3190
  2. Path: sparky!uunet!olivea!hal.com!decwrl!mips!darwin.sura.net!convex!constellation!geohub.gcn.uoknor.edu!dwight
  3. From: dwight@geohub.gcn.uoknor.edu (Dwight D. Moore)
  4. Newsgroups: comp.edu,comp.lang.fortran
  5. Subject: Re: scientists as programmers
  6. Message-ID: <1992Aug26.143702.21659@constellation.ecn.uoknor.edu>
  7. Date: 26 Aug 92 14:37:02 GMT
  8. References: <DAVIS.92Aug23010605@pacific.mps.ohio-state.edu> <1992Aug25.034553.2990@linus.mitre.org> <1992Aug25.154501.8654@colorado.edu> <1992Aug25.202307.12365@newshost.lanl.gov> <l9lrciINNb7b@almaak.usc.edu> <mcdonald.246@aries.scs.uiuc.edu>
  9. Sender: usenet@constellation.ecn.uoknor.edu (Nets)
  10. Reply-To: dwight@geohub.gcn.uoknor.edu
  11. Organization: Geosciences Computing Network, Univ. of Oklahoma
  12. Lines: 40
  13.  
  14. >
  15. >...too much stuff to include...
  16. >
  17. There are really several problems when considering a "good programmer":
  18.  
  19. 1. Good coding techiniques (modularity vs. the "one routine program", documenting
  20.      your code,  readability, declaring your variables explicitly, name your variables
  21.      something useful instead of "th" or "de",...etc)
  22.  
  23. 2. Efficient code (i.e. understanding the underlying concepts to improve code
  24.      performance). Do you index your array in declared subscript order (similar to 
  25.       memory order, i.e. a[i][j][k], this makes a difference). Do you minimize your
  26.       expressions (removing extraneous mults by rephrasing your equation) or
  27.       replace division by mults when possible?  I have seen where simple changes
  28.      in an equation in a loop improve performance and cut execution time in half.
  29.  
  30. 3. Documentation.  Do you document your code to indicate what is going on?
  31.       Readability, is part of documentation; the more readable your code is, the
  32.       easier it is to maintain, debug, port, etc. Is there paper documentation describing
  33.       methodologies, algorithms for your model, general approach to the problem?
  34.  
  35. Scientist that I have encountered generally learn (a few do, acutally) to write readable
  36. code, and pick up a few tricks for efficient coding. This depends on the scientists
  37. experience and training, but little exposure to good techniques, and good coding
  38. techniques inhibits, their growth.  If I taught a short lecture to a group of scientists,
  39. I would focus on #1 and #3 (too many people under -estimate the value of  #3) and
  40. work on #2 later...you can always improve your code efficiency after it works, but
  41. if it is hard to read, you will waste a lot of time trying to figure out where to start.
  42.  
  43. There is really a fourth category for using data structures, and maybe a fifth for
  44. advanced programming concepts, but that isn't necessary when talking about scientific 
  45. models and Fortran 77, which is probably still the best language for scientific models.
  46. ----------------------------------------------------------------------------
  47. Dwight D. Moore
  48. Geosciences Computing Network
  49. University of Oklahoma
  50.  
  51. dwight@geohub.gcn.uoknor.edu (129.15.40.10)
  52. These opinions do not necessarily represent the opinions of OU or the GCN.
  53. ----------------------------------------------------------------------------
  54.