[GRASS-dev] Re: 'g.gui wxpython' won't work in wingrass as wxgui is a shell script

[Ivan Shmakov]

>>>>> Michael Barton <michael.barton at asu.edu> writes:

 >>> Not really. Simple tasks can be done with just the GUI.

 >> One certainly won't go far only doing simple tasks.

 > 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].
	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.

[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.

	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.)

 >>> 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.

 > 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.

 > 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?)

 > 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?

	If there're particular strong points of Python, they're to be
	exploited first (is wxPython among the others?)