NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/edu/1395

Text File | 1992-08-29 | 3.7 KB | 83 lines

Xref: sparky comp.edu:1395 comp.lang.fortran:3266
Path: sparky!uunet!olivea!decwrl!zazen!doug.cae.wisc.edu!umn.edu!noc.msc.net!uc.msc.edu!shamash!ems!ems.cdc.com!mstemper
From: [e-mail] (Michael Stemper)
Newsgroups: comp.edu,comp.lang.fortran
Subject: Re: scientists as programmers (was: Small Language Wanted)
Message-ID: <21575@nntp_server.ems.cdc.com>
Date: 28 Aug 92 17:50:10 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Followup-To: comp.edu
Organization: Empros Systems International, a division of Ceridan
Lines: 67
Nntp-Posting-Host: kirk.ems.cdc.com

In article <[e-mail]>, [e-mail] (Wade Schuette) writes:
|>
|> 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."

I would stress the following points:

1. Write down your equations, formulae, algorithms, process description
   on the board (or a piece of paper) first. Make sure that you under-
   stand the physical reality that you are trying to model BEFORE you
   ever start thinking about writing a program.

   You're a scientist. You are smarter than a computer. You know lots
   of math. You understand the principles of the situation. This is
   why you get the big bucks. Use your talents to refine the problem
   statement and simplify it if possible.

   Have a firm goal in mind.

2. Before you write the code, write a program prologue or header. This
   is one to five paragraphs of comments at the beginning of the module
   that describes (briefly):
   A. Purpose of module
   B. Nature of inputs
   C. Nature of outputs
   D. How module goes from B to C. This can and should include references
      to books, papers (even your own), etc.
   E. Your name and the date

   What? You don't know all of that yet? Then you're not ready to write
   anything else, are you? This is the plan for your experiment or the
   model of your process. If you don't know this much about it, how do
   you think the computer can help you?

3. Now, start writing the module:
   A. Name some variables. If you have to deal with an Oxygen flow,
      call the value of that O2FLOW, not OF. But, if everything that
      you are dealing with is an Oxygen flow, don't call them OFLOWA
      OFLOW3, etc. Call them OFCOLD, OFHIGHP, OFXHAU, etc.
   B. Write comments marking off the major parts of the module:
         Get parameters
         Calculate load values
         Find overloads
         Print results
   C. Fill in the details by actually writing some code.

4. If this is truly a one-shot program written only because you left
   your calculator in your car, ignore 1-3 :->

Of course, this is the same advice that I would give anybody who wanted
to write good code. The only part that I would change for a non-science-
oriented audience would be not saying "You're smarter than a computer."

--
#include <Standard_Disclaimer.h>
Michael F. Stemper
Power Systems Consultant
[e-mail]