[GRASS-dev] Re: GRASS & programming

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

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

	It's unfortunate that this minority is ought to satisfy the
	evergrowing demands of the other part of the users.  It both
	makes the programmers strained by their work, and makes the
	users unsatisfied with the results.

	There's a certain line one has to cross in order to get into the
	programming.  And the current computer system marketers' motto
	``you don't have to learn to use it'' just makes it harder for
	an average user to do so.

[...]

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

	Well, you seem to be talking about the language syntax, and the
	programming language as a whole isn't only the syntax -- it's
	the standard library, too.  And thus the syntax used by its
	facilities belongs to the language.

	Thus, `expr' is, indeed, a part of the Tcl language, as well as
	its syntax.

	I don't think that it matters much, though.

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

 > foo(a+b, c+d);

 > looks like:

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

	Or, avoiding the textual substitution:

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

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

	Yes.  The aforementioned Tcl-nap package seems to help a lot by
	allowing, e. g.:

nap { a = { 1 .. 5 } }
nap { b = 2 * $a + 1 }

	A number of GNU R-like constructs is available as well, and even
	some ability to operate on georeferenced data (or is it?)

	Unfortunately, it has (had?) some problems with the build system
	(the use of M4 for C preprocessing C files contributed to it, I
	guess), some rather fundamental deficiences of the syntax, and
	it doesn't seem to be actively maintained nowadays.

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

	Yes.  That was the idea I wished to express when starting this
	discussion.

[...]

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

	Actually, Tcl's `eval' doesn't necessarily involve parsing.
	Rather, `eval' expects its arguments to be proper lists which
	are merged (`concat'enated) to produce a list to be evaluated.

	If the arguments to `eval' are strings, they're implicitly
	converted (parsed) into the respective lists as per the basic
	rule of the language.

 > 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're both ``string equality'' and ``number equality'' tests
	in Tcl:

% set a 12
12
% set b 12.0
12.0
% string equal $a $b
0
% expr { $a == $b }
1
% 

	You may compare it, e. g., to the presence of `equal?', `=',
	`string=?' and `char=?' in Scheme.

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

	Yes.  The allowance to construct structured values by
	constructing their respective string representations has it's
	benefits (and it's natural given the overall design of the
	language), but may quite easily lead one to write incorrect
	code, e. g.:

eval "$a $b $c"

	Instead of the proper:

eval [ list $a $b $c ]

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

	Yes, but there's at least the list representation and (starting
	with Tcl 8.5) the ``dict'' representation for the structured
	data.

	On the other hand, there's no way to make a foolproof
	programming language.  You may search the archives for ``buffer
	overflow'' for the ``evidence of deficiency'' of C pointers, for
	example.

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

[...]

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

	For as long as no clear dividing line between command-line use
	and scripting was shown to me.

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

	Agreed completely.

 > They would be a lot better off learning Python.

	I hope I'd be able to respond to this later.