multi-g.manuals; concurrency locking

Just a remark about Marks' last bit: I have to admit that the proprietary
macro language that we don't want to name here at least had the merit of
being rather easy to learn and providing almost all the access you
needed to the functionalities of the large software package that we
don't want to mention here, whereas getting into GRASS means using all
those tools like awk, sed, shell-scripting - in fact the standard UNIX
tools that make it such a hurdle to take for people who are interested
in just using the stuff (not mentioning the effort of learning C). And
isn't GRASS in itself a shell that provides access to basic UNIX
funcionalities? Speaking for myself, I always have been much more at ease
with macro (or 4GL) languages - but then again, sometimes I work on a PC,
and I just love working under Windows...

Philip Verhagen
--

      S t i c h t i n g R A A P

    Regionaal Archeologisch Archiverings Projekt

adress: Plantage Muidergracht 14
          1018 TV Amsterdam
           THE NETHERLANDS
phone/fax: (31) 20 525 5834
e-mail: motte@hacktic.nl

On Fri, 25 Mar 1994, motte wrote:

Just a remark about Marks' last bit: I have to admit that the proprietary
macro language that we don't want to name here at least had the merit of
being rather easy to learn and providing almost all the access you
needed to the functionalities of the large software package that we
don't want to mention here, whereas getting into GRASS means using all
those tools like awk, sed, shell-scripting - in fact the standard UNIX
tools that make it such a hurdle to take for people who are interested
in just using the stuff (not mentioning the effort of learning C).

I prefer to see the big picture here:

Why should I pay money for packaging control structures that already exist
in Unix tools, rather than for GIS functionality?

Many users don't just use a single system, GIS or otherwise. They use
several, and integrate them with each other the best they can. If each
different system has its own formalism for doing the everyday scripting
stuff (procedures, iteration, etc.) and for interfacing with the outside
world, then you've got to figure out how to use each one as a separate
case, and hope they can talk to each other efficiently. If designers would
take the approach (as in GRASS) of using what is provided by the
underlying platform, instead of repackaging everything so that it's all
nice and different and proprietary (the NIH syndrome), then you only need
to learn one system.

Finally, you can't really avoid having to use tools like awk or perl out
here in the real world. You have some ad-hoc, persnickety import problem,
and you can't afford to wait for some company in northern California to
upgrade their macro language so that you can get the coordinates out
northing first, or whatever. Sure, the manager types will do fine with
cut-and-dried visualization platforms where they just have to point and
click. Most GRASS users are analysts, however, and tend to be confronted
daily with the non-cut-and-driedness of the real world. In that kind of
context, you need the flexibility and bandwidth that can only be provided
by powerful languages.

And
isn't GRASS in itself a shell that provides access to basic UNIX
funcionalities? Speaking for myself, I always have been much more at ease
with macro (or 4GL) languages - but then again, sometimes I work on a PC,
and I just love working under Windows...

So what's the difference between macro/4GL and a Unix shell, awk, perl or
Tcl? Apart from the usual proprietariness of the former, I mean?

-- Mark

--------------------------------------------------------------------
Mark P. Line Phone: +1-206-733-6040
Open Pathways Fax: +1-206-733-6040
P.O. Box F Email: markline@henson.cc.wwu.edu
Bellingham, WA 98227-0296
--------------------------------------------------------------------