From: roo@dstos3.dsto.gov.au
Newsgroups: comp.edu,comp.lang.fortran
Subject: Re: scientists as programmers (was: Small Language Wanted)
Date: 28 Aug 92 00:04:52 GMT
Organization: Defence Science and Technology Organisation

> 
> Can we focus some attention on what CAN and SHOULD be taught to the
> scientists who would prefer to write good code and are reasonably bright
> but extremely busy.  On a very practical, very pragmatic basis.
> Suppose you can get 45 minutes of time, and hold a seminar on What every
> scientist should know about computing but probably doesnn't... or some such.
> 
> One shot.  The room is impatient. The top people are late. (the projector
> doesn't focus.) Now what?  This is a serious question, as I'd like to do
> precisely this, for an audience of primarily biological / chemical 
> researchers.  Software Engineering 101, extremely applied, for people
> heavily into Fortran and "getting results today."
> 
> Or maybe, this: if you had ONE thing you could try to get across, that would
> make sense to that audience in that time frame, what would it be?
> 

Well, speaking as a scientist who dabbles with programming I would probably
give emphasis to the basics :

    (a)  if you plan to reuse your code, or give it to other people, put some 
            useful comments in. The biggest problems I've encountered when
            other scientists give me code is receiving a subroutine, with no
            accompanying notes or comments, and I then have to work out what 
            twenty arguments and ten arrays in common blocks actually do (No,
            I'm not exagerating --- I had to spend 4 days with such a piece
            of code recently :-().

    (b)  in numerical work, you will often find that it's been done before.
            Be prepared to make use of NAG, IMSL, and good numerical packages
            like that. The approaches they use will often be better (faster,
            more accurate, etc.) that you could come up with yourself. If
            they're too cheap to pay, there are texts on numerical analysis
            (e.g. Numerical Recipes) and a number of good things in the public
            domain --- usually not as good as the proprietary stuff, but
            not bad. When you get some spare time, skim the documentation which
            passes over your desk so you can be aware of where you might find 
            things you could need in the future.

    (c)  remember, the computer can't do your work for you. A number of 
            scientists on computers who I know fall back on number crunching 
            when they can't solve it by hand, and apply a brute force 
            approach --- looping over a large range in each of 20 variables
            will eventually produce results, but only after a lot of grunt
            is applied, and then you have to pore over many pages to find the
            useful stuff. A bit of thought before unleashing the CPU can save
            buckets of time.

    (d)  when you are testing code, test out one bit a time. Don't throw
            together a large package, and try to fix all the problems at
            the end.

    (e)  in a similar line to (d), when you receive code from someone else,
            test it out using some (hopefully simple) test cases. A classic
            I know of from my University days involved a PhD student who
            got code via E-mail from a researcher overseas. After 6 months
            of runs on almost every computer in the university, he stopped and
            had a look at the data coming out. It was garbage. Turned out that
            about two or three lines in a crucial subroutine got munged in
            transmission.

Just my 2 cents worth.
                       Robert
    

-- 
---------------- <Standard Disclaimer>
Robert O'Dowd                              Phone  : +61 8 259 7132
Bldg. 64 TSAN,  AS/MOD                     Fax    : +61 8 259 6104
P.O. Box 1650                              E-mail : roo@dstos3.dsto.oz.au
DSTO Salisbury, South Australia               OR    roo@dstos3.dsto.gov.au
                                              OR    roo@mod.dsto.gov.au
Disclaimer: Opinions above are MINE, and probably worth what you paid for them.
Newsgroups: comp.edu,comp.lang.fortran