[GRASS-dev] GRASS & programming

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

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

	I'll try to keep the above in mind while replying.

	I should also note that I'm primarily concerned with the
	programming expertise (or rather, the lack of) of natural
	scientists, too.  So I believe we aren't contradicting each
	other that much.

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

	It is unnecessary for computer programmers to have experience
	with programming?  That sounds strange, at least.

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

	It depends on where we'd draw a demarcation line.

	Given the number of devices which do contain certain electronic
	circuitry within them, and that that circuitry is often based on
	MCUs, which are, technically, almost finished computers, it
	seems to be obvious that it isn't necessary to learn programming
	in order to use an MCU-powered flat iron, or a car.

	On the other hand, a desktop computer is not a flat iron.

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

	It's rather a task the great majority of computer users never
	heard nor thought of.  And how could one decide whether he needs
	something, if he's unaware of its presence beforehand?

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

	Unfortunately, yes.  There's a certain mismatch between the
	present state of affairs (as I view it) and my expectations.
	That contributes a share to my motivation to work in the field.

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

	Yes, so every opportunity has to be exploited to shorten this
	time, unless the quality of the learning will degrade as a
	consequence.

 > Why should they learn 2 or more computer languages when it is of no
 > use to getting their work done?

	Could you please name a field of human activity which doesn't
	rely on one doing repetitive tasks and where the use of
	computers would be appropriate at the same time?

 > Why would any employer want their employee to do so when it is
 > unnecessary to use a computer?

	The concerns I've expressed were solely about the computer
	users.

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

	So we should ensure that GRASS continues ``to remain completely
	scriptable.''

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

	Do we want for the programming tools to be accessible to a very
	limited group of specialists instead?  And it's what we're going
	to go by assuring the ``average users'' that the present day's
	use of computers doesn't require one to program anymore.

 > People should learn programming if it helps them solve problems.

	People should learn the basics of programming to be able to
	decide whether it will help them solve problems.

	One's perception, and one's decisions, are heavily influenced by
	the prior experience and knowledge.  There's no way for you to
	decide the applicability of a tool, or a certain knowledge,
	without knowing a bit of it first.  And my personal experience
	shows that the majority of computer users just don't know what
	the programming is for, nor what they could achieve by writing
	programs.  And once this matter is clarified at least a bit,
	some of them become quite eager at getting in it.

	To clarify it is the hardest part, though.

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

	However, you should note that speech is the most developed form
	of human communication.  It's probably the most robust as well.
	It exists in a variety of forms -- oral, written, braille.  How
	would you transmit a gesture by phone?  Would gestures help you
	to communicate with a visually impaired person?

	You may consider comparing the popularity of the Picto and
	Esperanto languages.  While Esperanto is actively used, Picto
	seems to be mostly forgotten.  I relate this to the fact that
	Picto wasn't based on a conventional writing system.

	I don't know whether to use letters or symbols (and isn't
	`printf' a symbol?) is a ``natural'' or ``normal'' way for
	humans to communicate, but I'm quite certain that this way was
	used broadly throughout the history of mankind.  So, yes, it was
	the history why the computational devices are controlled by
	typing words.  But it's not just the history of computation.

	As to the use of English, it became the international language
	for the computer-related matters.  And yes, it's not
	unreasonable for a computer user to learn English in order to
	use computers as well.  Having said that, I do /not/ think that
	the i18n and l10n efforts are a waste of time.

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

	I agree with the above.

 > But this is not an either or with GUI use. One should not be forced
 > or encouraged to use either method to access commands.

	There's no need to force anyone to use either method.

 > In fact, I'd love to see the addition of other ways to manipulate the
 > tools that make up GRASS.

	So would I.

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

	Either way, it'd be a symbolic notation for writing programs.
	It hardly matters, whether it'd be a word (`mov'), a
	pseudographical symbol (`:=', `<-'), or a graphical arrow, to
	represent an assignment, for example.

	But certainly, a rich set of tools to manipulate ASCII files is
	available, and if the program isn't stored in such a file, it
	may become troublesome to handle it in automagical ways.

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

	For the reasons I hope I've explained above, I doubt that that'd
	be an effective mean of programming.  However, I have no intent
	to prevent, or discourage, anyone from experimenting in this
	field.  It may be quite an enlightening experience, after all.

[...]

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

	It depends on what you do mean by ``calling'', and how it's
	different from ``signalling''.  IIRC, there were a lot of Tclers
	to consider the `expr' syntax separate from the Tcl's own one.

	As for a little language that is (or was?) available for Tcl as
	a separate package, you may consider Tcl-nap:

http://tcl-nap.sourceforge.net/

	On the other hand, per POSIX, AIUI, C preprocessor is a part of
	C, and `expr' is a part of the Shell language.

[...]

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

	Could you outline a few of advantages of Python over Tcl (i. e.,
	without Tk)?

 > It is also a lot easier to use than bash.

	I guess that depends on a task.

	Is Python suitable for use as an interactive Shell for GRASS,
	for instance?

 > And this will hopefully will encourage more people to try their hands
 > at programming tasks in GRASS.

	I hope so.

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

	However, given that with the transition to Python a POSIX Shell
	will become optional, some of the GRASS/W32 users may become
	inclined to use cmd.exe with GRASS.  And it doesn't seem to be a
	particularly good way to encourage GRASS users to try GRASS
	scripting.

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

	If it would, then go for it.

	But I doubt it would unless a considerable time is put into the
	creation of an adequate library of wrappers.

[...]