[GRASS-dev] GRASS & programming

[Glynn Clements]

Ivan Shmakov wrote:

>  >> 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 would agree that it's at least useful (even if not absolutely
necessary) for *programmers* to have programming experience.

However, the demand for programming skills is growing faster than
those skills can be acquired. Consequently, the average level of
experience is decreasing.

Nowadays, there are a lot of programmers whose only experience is the
PHP/JavaScript web application for which they learnt programming in
the first place.

If you're thinking of programmers in terms of people with Computer
Science (or Software Engineering etc) degrees, or people who taught
themselves back in the days of the 8-/16-bit home micros, they're a
small minority. There are many more people who started off as web
designers and have learnt just enough PHP/Perl/Java/JavaScript to get
the job done. Or who learnt VB/VBScript for writing MS-Office macros.

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

There is a never-ending tension between simplicity and capability. 

This tension tends to manifest itself as an argument between those
believe that simplicity is the ultimate goal, and those who also want
capability.

Unfortunately, the simplicity camp tends to grant zero weight to
capability issues, and often tries to paint those who also want
capability as simply being fundamentally oppsed to simplicity.

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

I would agree that "expr" is not part of the Tcl language. It's a
standard function, not a language construct. In most languages,
arithmetic is a language construct (except functional languages, where
almost everything is a standard function, but there, each arithmetic
operator is a separate function).

This is relevant insofar as e.g. the C expression:

	foo(a+b, c+d);

looks like:

	foo [expr $a + $b] [expr $c + $d]

in Tcl. The Tcl syntax is rather ugly if you do a lot of arithmetic.

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

On the last point, "expr" *may* be a shell built-in, but it may also
be an external command.

So far as POSIX is concerned "may be a shell built-in" simply means
that you can't assume that you can invoke it directly via e.g. 
execl(), as it might not exist as a separate program. If you're
writing a shell script, it doesn't matter whether something is a
built-in.

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

Tcl has many of the same defects as the Bourne shell.

Languages which are based primarily upon textual substitution are
simple to implement, and it's simple to describe the (relatively few)
rules which define the language, but they're a nuisance to program in.

Such languages tend to encourage over-use of "eval", which produces
messy code, and can cause problems when data values contain language
metacharacters (Lisp's "eval" doesn't have the latter problem, as it
doesn't involve parsing).

Another problem is the "everything is a string" model. This creates
problems with different representations of the same value. E.g. are
"12", "12.0" and "012" all equal? There are also problems with
constructing structured values (e.g. lists) using string operations,
e.g.:

	set x "$a $b $c"
versus:
	set x [list $a $b $c]

The former does the wrong thing when a variable contains spaces.

If you want more evidence of the problems with the use of textual
substitution in programming, search the archives of BugTraq and other
security-related lists for "SQL injection" and "shell injection". 
Manipulating structured data by manipulating its string representation
will always be error-prone.

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

Not at all. For similar reasons, interactive shells aren't
particularly suitable for use as programming languages.

The Bourne shell is a good interactive shell because it was designed
for use as an interactive shell. It isn't a good programming language
because it was designed for use as an interactive shell, not as a
programming language.

cmd.exe isn't a particularly good interactive shell, but it's good
enough for most usage. Although bash has far more features, most of
them are primarily for use in scripts rather than interactive use.

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

For how long are you going to keep trying to conflate command-line use
with scripting?

Right now, we include Bourne-shell scripts and a Bourne shell. When
the scripts are written in Python, we'll include (or at least require)
Python.

Neither of those will be familiar to the average Windows user, so if
they want to write scripts, they need to learn one. They would be a
lot better off learning Python.

-- 
Glynn Clements <glynn at gclements.plus.com>