Comments on scripts, modeling and Grass

[Rich Shepard]

On Wed, 27 Oct 1999, Agustin Lobo wrote:

> Well, this demonstrates that C is not a good language for modeling, as you
> have to repeat each line in a different language. Would English be an
> adequate language for this message if I had to repeat every paragraph in a
> different language because virtually nobody (even not myself!) could
> understand what I'm saying?  (OK, sometimes my English can be so obscure
> that this problem could actually be real!).

Augustin,

  I did not make myself clear. C code is very easy to read and understand,
however, regardless of what language one uses (C, FORTRAN, English or
Spanish), _why_ you did something a certain way or in a certain order is not
always intuitively obvious.

  Let me try an analogy or two: Have you ever tried baking breads? Do you
realize that the sequence in which the ingredients are added can make a big
difference in the texture and taste of the final product? That's why recipes
are written down. And, if we try to do it from memory (and we haven't made
that recipe in a while), we may be disappointed with the results if we
change the sequence.

  Another situation: major construction work in the city's downtown, core
area. We read about it in the newspaper, but we forget just how we got to
our destination. The next time we need to go to the same place, we get stuck
in traffic and wonder how we managed to avoid it the last time.

  In both analogies (probably pretty poor for 6 am), the material (bread
making technique or vehicle type) is not the issue. The issue is the
process. Same with coding models. It's not the complexity of the language
which needs commenting, it's the algorithm.

  If you want to use something written in English (for example), try writing
scientific models in COBOL. Plain English words. But, my son told me when he
wrote insurance company software as his first job out of college, it can be
as obtuse to understand as the most obfuscated C.
 
> Note that I'm talking about modeling. I understand that, in other
> applications, FORTRAN, C, C++,..., can be the best alternative. But, in
> modeling, often you cannot evaluate the program just by the result. If you
> write a program to display an image, you can easily detect an error in the
> code because the display would be wrong. Or if you write a program to
> calculate an FFT you can use a simple input and compare the result to your
> own computation or to the result produced by another FFT program: the
> result is predictable. Instead, in modeling, the result is not predictable
> (yet): that's why you make the model. Also, you can have a CORRECT result
> out of a WRONG model: the result must be produced by processes that are
> physically, biologically, ecologically... consistent, and this should be
> assessed by other scientists being able to read the code. Which implies a
> simple syntax with, ideally, one action per line.

  My point exactly. The coding langguage is immaterial. You want a way to
understand the program's logic and algorithm. I suggest that comments in the
source code are the only way to do that. Well, ... you could always write an
accompanying "users manual" which explained the logic and algorithms, but
then that would probably get misplaced. 

  Trying to identify the one, "right" language or tool will lead you in
circles. We've all suffered through discussions (arguments, flame wars,
whatever) over which programming editor is best (emacs vs. vi in the world
of unices), which linux distribution is best, which programming language is
best, and so on. In my opinion, two of the reasons there are so many
scripting languages available in the world of linux are 1) someone wanted to
do something which is not well or easily done with existing tools and 2)
there's ego gratification to produce a tool used and admired by others.

  So much depends on what you want to do. I prefer to grab the closest tool
-- the one I know the best -- to solve the problem and move on with the
answer. Others perfer to focus on selecting exactly the right tool for the
job, even if that takes precedence over getting the job done. We all have
different priorities, needs and preferences. One of the things I like best
about the linux environment is the abundant choice of tools and solutions.
Everything will work, and we can each pick our solution of choice.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)         
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
 + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard at appl-ecosys.com