Implicit binding and ergonomics (was Re: ... too complicated)

[Clayton Weaver <cgweav@eskimo.com>]

(unlurk)

What have you have here is a problem of ergonomics, actually
a question of "ergonomics for who exactly?"

Eating at Joe's (Duntemann's old example):

We just arrived in town (beginning scheme programmer), and we
decided to have lunch at Joe's, which is world famous.
We're driving through town (looking at someone else's code),
and we notice what wonderful, new, smooth roads we have here
(functions as first class objects, lack of clutter in the syntax).
However, the place seems to missing some of the street signs
(implicit binding and free variables). Instead of a big sign that
says "Turn here to Eat at Joe's", or even the name of Joe's street,
we have to slow way down at corners and peer down the side street
to see if Joe's is down there (we have to discern the scope of free
variables getting bound from out of this forest of ((())) characters
mixed with other syntax).

Which is more ergonomic, the big sign ("{a = x + 1;}") or the implicit
binding in lisp and scheme? For whom, exactly? Once you can see where
variables are free in the body of a function and the scopes where
they get bound, scheme becomes ergonomic (less typing to write code).
But up until then, the programmer is driving around, trying to find
Joe's by trial and error. That programmers who haven't already learned
lisp or scheme for their own reasons view this as obtuse and not
user-friendly compared to the big "Eat at Joe's" sign should not be
surprising. It's like uncommented forth. perl at least has ";".

"while" is more obvious than recursion, but once the correspondence
between a loop and a recursion is explained with one particularly
lucid example, it is no longer incomprehensible, and besides,
you can make looping constructs that are just aliases for
recursive definitions (have your cake and eat it to).

And why did the language designers leave out the "else" in "if condition
do () else do ()"? This is at least as perverse from a programming
language student's viewpoint as implicit binding of free variables. 

It's not functional semantics that is at issue, it is not data structure
complexity, it is "how long will it take before this language is useful
to me in the tasks that I have to accomplish".

Implicit binding generates higher training costs over the industry as a
whole.

What I would do is redesign the syntax with the moral equivalent of
street signs that clearly show in the code the scope of variable
bindings. Assuming that isn't really an option given the goal of
easy importing of existing scheme code, the only alternative is
really good examples that don't leave out any details, as if you
were explaining the very idea of a variable to someone who had
never written a single line of code before.

Without that, people will still use guile (it does have a complete
programming language's capabilities and the semantic elegance of lisp),
but you won't make a dent in the market for imperative scripting languages
where scope of variable binding is obvious (imho).


-- 

Regards, Clayton Weaver  <mailto:cgweav@eskimo.com>  (Seattle)

"Would that be 30 gallons of the Summer Paint or 30 gallons of
 the Winter Paint?"