home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / edu / 1371 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  4.5 KB
  1. Xref: sparky comp.edu:1371 comp.lang.fortran:3209
  2. Path: sparky!uunet!munnari.oz.au!yoyo.aarnet.edu.au!dstos3.dsto.gov.au!roo
  3. From: roo@dstos3.dsto.gov.au
  4. Newsgroups: comp.edu,comp.lang.fortran
  5. Subject: Re: scientists as programmers (was: Small Language Wanted)
  6. Message-ID: <1992Aug27.180452.164421@dstos3.dsto.gov.au>
  7. Date: 28 Aug 92 00:04:52 GMT
  8. References: <1992Aug25.034553.2990@linus.mitre.org> <1992Aug25.154501.8654@colorado.edu> <1992Aug25.202307.12365@newshost.lanl.gov> <1992Aug26.102735.12519@wl.com>
  9. Organization: Defence Science and Technology Organisation
  10. Lines: 73
  11.  
  12. > 
  13. > Can we focus some attention on what CAN and SHOULD be taught to the
  14. > scientists who would prefer to write good code and are reasonably bright
  15. > but extremely busy.  On a very practical, very pragmatic basis.
  16. > Suppose you can get 45 minutes of time, and hold a seminar on What every
  17. > scientist should know about computing but probably doesnn't... or some such.
  18. > 
  19. > One shot.  The room is impatient. The top people are late. (the projector
  20. > doesn't focus.) Now what?  This is a serious question, as I'd like to do
  21. > precisely this, for an audience of primarily biological / chemical 
  22. > researchers.  Software Engineering 101, extremely applied, for people
  23. > heavily into Fortran and "getting results today."
  24. > 
  25. > Or maybe, this: if you had ONE thing you could try to get across, that would
  26. > make sense to that audience in that time frame, what would it be?
  27. > 
  28.  
  29. Well, speaking as a scientist who dabbles with programming I would probably
  30. give emphasis to the basics :
  31.  
  32.     (a)  if you plan to reuse your code, or give it to other people, put some 
  33.             useful comments in. The biggest problems I've encountered when
  34.             other scientists give me code is receiving a subroutine, with no
  35.             accompanying notes or comments, and I then have to work out what 
  36.             twenty arguments and ten arrays in common blocks actually do (No,
  37.             I'm not exagerating --- I had to spend 4 days with such a piece
  38.             of code recently :-().
  39.  
  40.     (b)  in numerical work, you will often find that it's been done before.
  41.             Be prepared to make use of NAG, IMSL, and good numerical packages
  42.             like that. The approaches they use will often be better (faster,
  43.             more accurate, etc.) that you could come up with yourself. If
  44.             they're too cheap to pay, there are texts on numerical analysis
  45.             (e.g. Numerical Recipes) and a number of good things in the public
  46.             domain --- usually not as good as the proprietary stuff, but
  47.             not bad. When you get some spare time, skim the documentation which
  48.             passes over your desk so you can be aware of where you might find 
  49.             things you could need in the future.
  50.  
  51.     (c)  remember, the computer can't do your work for you. A number of 
  52.             scientists on computers who I know fall back on number crunching 
  53.             when they can't solve it by hand, and apply a brute force 
  54.             approach --- looping over a large range in each of 20 variables
  55.             will eventually produce results, but only after a lot of grunt
  56.             is applied, and then you have to pore over many pages to find the
  57.             useful stuff. A bit of thought before unleashing the CPU can save
  58.             buckets of time.
  59.  
  60.     (d)  when you are testing code, test out one bit a time. Don't throw
  61.             together a large package, and try to fix all the problems at
  62.             the end.
  63.  
  64.     (e)  in a similar line to (d), when you receive code from someone else,
  65.             test it out using some (hopefully simple) test cases. A classic
  66.             I know of from my University days involved a PhD student who
  67.             got code via E-mail from a researcher overseas. After 6 months
  68.             of runs on almost every computer in the university, he stopped and
  69.             had a look at the data coming out. It was garbage. Turned out that
  70.             about two or three lines in a crucial subroutine got munged in
  71.             transmission.
  72.  
  73. Just my 2 cents worth.
  74.                        Robert
  75.     
  76.  
  77. -- 
  78. ---------------- <Standard Disclaimer>
  79. Robert O'Dowd                              Phone  : +61 8 259 7132
  80. Bldg. 64 TSAN,  AS/MOD                     Fax    : +61 8 259 6104
  81. P.O. Box 1650                              E-mail : roo@dstos3.dsto.oz.au
  82. DSTO Salisbury, South Australia               OR    roo@dstos3.dsto.gov.au
  83.                                               OR    roo@mod.dsto.gov.au
  84. Disclaimer: Opinions above are MINE, and probably worth what you paid for them.
  85.