On Fri, 25 Mar 1994, Jaro Hofierka wrote:
Dear Mark,
I am more a scientist than a programmer but I am sufficiently
familiar with Unix and I have been programing several GRASS
programs. However I must tell you that I would rather prefer
GRASS running on a PC under Windows NT (or Windows 4.0) than on
Unix box. It is PLEASURE working under windows on a PC and
work is much faster (just clicking on icons and menu).
De gustibus non esse disputandum. What icons and menus would you like me
to provide you with so that you can use the point-and-click method to
develop r.binfer scripts? r.combine? How about controlling ps.map? You
design the user interface, and I'll build it. But not for any Microsoft
platform. 
Plenty
of available SW for funny low prices allow me to combine those
SW packages which are best for solving a specific task.
Precisely. Linux, XFree, GRASS, Khoros, Tcl/Tk, ...
> 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.
I think you miss the point a little bit. Most of users are
like Mr. Frank Davis - they want use GRASS immediately solving their
problems and not deeply learn Unix, C and shellscript programming.
I guess I didn't express my thoughts clearly enough. What you're saying
here is perfectly analogous to saying, "I'm sorry officer, I just wanted
to drive to the grocery store, not deeply learn driving, parking and
traffic signs". As I mentioned above, if you can think of a way to stick
functionality like r.binfer into a pristine point-and-click GUI, let me
know.
User interfaces to software have to match the "bandwidth" of the software
being controlled. Point-and-click-type interfaces have a very low
bandwidth, which is fine if that's what your underlying software has. Some
parts of GRASS have such low bandwidth: d.rast, d.erase, d.frame if you
break it down into component actions, etc. Other parts of GRASS, however,
have a *very* much greater bandwidth: r.[b]infer, r.combine, p.map and so
on. Trying to force high-bandwidth software under a low-bandwidth user
interface will only cause problems.
Another high-bandwidth aspect of GRASS is the way in which smallish
analysis tools can be bound together through a pipeline or, if need be,
through a file interface. Now, there are good approaches to casting this
kind of functionality in the form of a GUI: the "direct-manipulation
dataflow" approach used by Cantata (Khoros) and the AVS network editor.
Maybe somebody will be sticking GRASS under Cantata one of these days.
My main point is that it is
The task of
GRASS programmers is to provide powerful and easy-to-use tools and not to
tell them: use awk, sed or make your own program.
Whom do you mean by "GRASS programmers", and who defines what their "task"
is? You can only mean (a) GRASS programmers at CERL or (b) GRASS
programmers outside of CERL. CERL programmers know what their tasks are,
and they are not bound by what you or I think they are, because they have
their own clientele (to which neither you nor I belong). GRASS programmers
outside of CERL are almost always GRASS users who find they need to do
some programming or shell scripting along the way. The number of GRASS
programmers outside of CERL who are not primarily GRASS users you can
count on the fingers of one hand. I'm one, some people at Osiris are too,
and I suspect that Gilles Clement would put himself in that category.
There are others. But pretty much all other GRASS programmers *outside*
CERL have user-oriented agendas related to their tasks (or their
organization's tasks) as GRASS users. So: CERL programmers' tasks are
defined by somebody other than you or me; other programmers' tasks are
defined by somebody other than you or me (except that I define my own
tasks as a GRASS programmer).
Therefore, when you say:
The task of
GRASS programmers is to provide powerful and easy-to-use tools and not to
tell them: use awk, sed or make your own program.
I think you're forgetting where GRASS is coming from (literally) and how
it is developed. If you do not want to do your own GRASS programming, but
have good suggestions on how you think GRASS could be improved, you should
definitely post your ideas to one of the GRASSHopper lists. Maybe somebody
will take you up on your ideas. If you keep them to yourself, they can't.
As to "easy-to-use", please see my separate posting on grassu.
-- 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
--------------------------------------------------------------------