On Mar 19, 2008, at 7:11 PM, grass-dev-request@lists.osgeo.org wrote:
Date: Wed, 19 Mar 2008 23:10:29 +0600
From: Ivan Shmakov <ivan@theory.asu.ru>
Subject: [GRASS-dev] Re: 'g.gui wxpython' won't work in wingrass as
wxgui is a shell script
To: grass-dev@lists.osgeo.org
Cc: Ivan Shmakov <oneingray@gmail.com>
Message-ID: <m2lk4efxmi.fsf@cherry.siamics.int>
Content-Type: text/plain; charset=us-asciiMichael Barton <michael.barton@asu.edu> writes:
Not really. Simple tasks can be done with just the GUI.
One certainly won't go far only doing simple tasks.
First a context statement that may seem a bit odd given my comments below. I strongly encourage social and natural scientists to be able to think about processes in algorithmic terms -- "computational thinking" in current NSF jargon -- and I have several large projects in the works to develope ways to encourage this broadly in the sciences. I also program, although completely self taught with all of its pitfalls, and encourage my students to learn programming skills as needed.
Actually you can do some pretty complex stuff with the GUI. Try it.
Actually I've meant the ``... but it might take you a LOT
longer...'' cases specifically here.Nowadays, it seems that even computer programmers, let alone
users, have very little experience with programming [1].
Agreed. In many cases it is simply unnecessary. I think that it is a good idea to know how an automobile works and be able to do some level of repairs or maintenance on it. BUT for many people, this is a waste of very precious time and unnecessary in order to drive the car from point A to point B. When I was a graduate student, one had to learn to program to get any use out of a computer. Now you can do an enormous amount of useful work without knowing a bit of programming. I think this is great. Nothing wrong with programming. But why MUST one learn it when it is not necessary to use the computer as a tool?
Consequently, even a simple ``show me a MODIS Total Totals index
on a map'' task becomes unsolvable by adding a ``... for every
day of july, 2007'' bit to it.
Yes, this is a task that programming would help with. But it is a task that the great majority of computer users never need to do.
[1] http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html
Perhaps, my perception is influenced quite heavily by my
experience with remote sensing (and to have 100 rasters per day
for a monthly interval is hardly an untypical situation.) But I
really believe that an ``average computer user'' is expected to
know at least a couple of programming languages.
This doesn't match with your statement above. In fact, I'd wager that the average computer today user knows absolutely NO computer language at all. People have a lot to do in limited time. Learning and using programming languages requires a significant investment of time. Why should they learn 2 or more computer languages when it is of no use to getting their work done? Why would any employer want their employee to do so when it is unnecessary to use a computer?
Unfortunately, typical GUI cannot be easily programmed and thus
(as it seems to me) discourages programming way too often.
(Though the GRASS GUI seems to be on the right way to overcome
this problem.)
So we should make applications more difficult to use so that users are forced to get the character-building experience of learning to program? That doesn't seem to be a good way to make analytical tools available to users who need them. That seems a way to make sure that only a very limited group of specialists can use computational tools. Is that what we want?
People should learn programming if it helps them solve problems. There is no reason except the history of computation why computational devices should be controlled by typing English words on a screen in a particular syntax. Furthermore, typing words is not the not a particularly "normal" way for humans to manipulate representations of spatial relationships. We are much more accustomed to represent spatial relationships through gestures, for example.
More complex tasks really deserve a proper programming language. The
range inbetween, where bash is a reasonable solution, is actually
quite narrow.The only thing that I have to say in the defense of Bash is that
the little languages always have a narrow, but not a negligible
niche.The thing that bash allows you to do is to chain together the same
commands that you get in the GUI. That is, you can do the same stuff
in the GUI that you can do by scripting, but it might take you a LOT
longer to accomplish it.Well, yes, but would one's actions be accurate after doing the
same for 10 times? or 100 times? or 1000?Apart from the obvious unreliability of a tired user, any real
life task has its time constraints.
I agree absolutely. This is the advantage of being able to script GRASS if you need and want to do it. A GUI has its place and so does combining operations to automate a series of repetitive, error-prone tasks. This is why GRASS definitely needs to remain completely scriptable. But this is not an either or with GUI use. One should not be forced or encouraged to use either method to access commands.
In fact, I'd love to see the addition of other ways to manipulate the tools that make up GRASS. For example, a year ago, I saw a demo of a great visual environment for creating GIS models by combining commands. Some command objects could be nested inside other command objects or linked to command objects through graphic representations. OSSIM does something along this line.
I personally might prefer to type some stuff--because I'm used to it--but this could be a very powerful way to apply algorithmic thinking to the creation of multi-process, interative geospatial models.
Any scripting language that can interact with GRASS commands (i.e.,
most of them) can serve this same purpose. You can do it with Python,
PERL, Java, TclTk, etc. Bash is handy because it comes preinstalled
on Linux and Mac systems (and sh on earlier Unix systems) and was
consistently available even when other scripting languages were not.
It is only for this historical reason that it has become a standard
for scripting in GRASS.Yes.
IMHO, it's a pretty primitive and opaque programming language (e.g.,
you have to use another scripting language like awk to do floating
point math).That's quite a frequent practice (consider, e. g., `expr' in
Tcl, or Cpp for C.) I don't think it should be afraid of.
expr does not call another language in TclTk, it simply signals to evaluate an expression--any experession.
You can do a lot with it, but it is not easy to do or to deconstruct
(or debug) what others have done. I say this in spite of having made
a number of the existing GRASS Bash scripts, including some pretty
complex ones (e.g., d.vect.thematic).Real programmers can write Shell in any language, I guess.
To put it serious, it seems to me that the potential of the
Shell wasn't fully exploited. (After all, where's that library
of the Shell functions deemed useful for a GRASS programmer?)With GRASS 7 and opening up of GRASS for Windows, we have an
opportunity to modernize scripting on GRASS (Note I am not a Windows
user). There will always be people who script in Bash. It's great
that one can do so.Yes, it certainly makes sense to support many different
languages available for GRASS scripting.However, I think that it would benefit the community settle on a new
scripting "standard" that is truly cross- platform and an easier,
more up-to-date, powerful, and easier to use language. There are
several good candidates for this, but Python has a number of
pragmatic advantages in the current context.Indeed, it may be a reasonable decision. (Though it'd be
interesting for me to know what are the particular problems with
Tcl, which is both portable and was used in GRASS for quite some
time?)
TclTk is a nice GUI platform, but there are some limitations especially with the creation of graphic canvases. We went through them in detail a couple years back. It's on the WIKI I think. If not, I think I've got copies of the discussions and can send them to you. It also turns out that TclTk for Mac has problems, which is why GRASS for Mac is distributed with X11 TclTk instead of the aqua version--though maybe these are getting fixed with 8.5 and above.
However, beyond a platform for GUI development, Python (i.e., not wxPython) is more full-featured as a general purpose programming language. It is also a lot easier to use than bash. And this will hopefully will encourage more people to try their hands at programming tasks in GRASS. I don't want to make programming a requirement, but I DO want to make it easier for users to create programs to solve problems with GRASS when they need to do so. And I DO want to encourage social and natural scientists to conceptualize system dynamics in algorithmic ways. This is easier done if people have some programming experience.
What this means is that we need to have Python people volunteer to
begin to rewrite existing Bash scripts in Python and begin writing
any new scripts in that platform so that we can have the critical
mass to encourage others to learn it and write in it. A couple people
have started on this.I'm afraid that an attempt to rewrite /all/ the Shell scripts in
Python will both take time and bring some mess along. Would
you, e. g., consider an untested 100-lines Python substitute for
a 50-lines Shell script (that's known to be working for years)
to encourage anyone to write in Python?
Actually, from my limited experience, I'd suspect that it would be the other way around--50 lines of code or less in Python to replace 100 lines of bash shell script, and be easier to read.
The shell scripts distributed with GRASS are an integral part of the distribution package. To the average user, they are functionally equivalent to the modules programmed in C. We need to replace shell scripts with the same functions in a portable cross-platform language if we want GRASS to work well on non-POSIX systems (primarily Windows). IMHO, it would be (and is) problematic to continue to release GRASS with a significant number of critical modules that fail on a very common OS. There really aren't all that many that would need to be replaced. Some of them might well even work better if re-written.
If there're particular strong points of Python, they're to be
exploited first (is wxPython among the others?)
Python is the general purpose object-oriented programming language. wxPython is a Python port of the wxWidgets GUI interface development platform. You can do all scripting of GRASS in Python without employing wxPython at all. However, Python is needed in order to use wxPython for GUI development.
Michael