Newsgroups: comp.sys.mac.misc

Clark Goble writes:

> But
> the Lisp like programming you gave still causes a few problems, unless
> you use it consistantly.

Inconsistent use of any programmable interface is hazardous, to say
the least.

> If you have a good metaphor (data in a pipe)
> then it is easy for the user to quickly do things.

The Lisp metaphor is quite simple: a function evaluates its arguments
and passes the results as an argument to a successor function.  I
taught this notion to elementary-school children through the use of
the Lisp-like Logo language (and simpler terminology!), and they
grasped it without difficulty.  The prefix notation of Lisp is no
challenge to learners if it is introduced in a reasonable way.

> The problem with
> most CLI is that there is no metaphor at all.  I suppose it is suppose
> to be 'English like language' (the catch phrase from a few years back).
> But the most English like langauge I have used is Hypertalk and I still
> hate it.

English is a wonderful language for people and a terrible one for
computers.  Functional languages are reasonably comprehensible to both
parties.

> Yes.  And those who want to know about the innards tend to use their
> computer more efficiently.  It is like a car.  If you know how it
> works, you tend to drive better.

Well, maybe.  More to the point, if you understand something about the
engine, and you see the oil-level warning light come on, you'll stop
the car immediately because of your understanding.  You could be
taught explicitly to "stop the car when that light comes on," but your
relationship with the automobile is then fundamentally different.

> But many people want a computer to
> be an invisible tool.

It is worth pondering what this "invisibility" costs.  One can argue
that freeing the user from any obligation to understand his computer
allows him to concentrate on other tasks.  But consider the insidious,
ubiquitous and progressive "dumbing-down" of the user's technical
capacity and the consequences of the sequestering of computer
knowledge to an expert elite.  The computers are out on the people's
desks, but the expertise is somewhere behind glass walls.  This is not
what the personal computer "revolution" was all about.

> Doing the act should almost be unconcious.
> 
> That is always my test of good mac software.  Can I do it without thinking
> much beyond what I want to accomplish.

Are users limited in any substantial way if they become expert in the
use of tools, but they remain ignorant of the nature of their tools?
That is the question of this age, and our fate is tied to it.

> And in a real sense Apple events are more
> powerful than anything under UNIX.  Applications become the programming
> language.

I must investigate Apple Events.  I suspect that they owe something to
the "hairy control structures" that Carl Hewitt investigated for the
Actor language in the 1970s.  Just as the classic Lisp paradigm of
"multiple inputs/one output" transcends the one-dimensional nature of
the Unix pipe, "hairy" control structures move beyond Lisp to allow
reasonable structuring of multiple (even conditional) outputs to a
variety of receiving functions.  User-level representation of such
structures and communication channels in any interface (character or
bitmapped) remains a challenging problem in cognitive science.

> Lisp has its power, the once again the metaphor is poor.

Actually, the problem is instructional, not cognitive.  Lisp is so
very simple -- it's usually just not taught simply.

> Try reading a complex Lisp program and figuring out what you did.
> It's fine for small things.  But get to big....

Solution: don't write big functions.  Lisp programs that are in fact
arcane usually owe their opacity to the programmer's attempt to
achieve higher performance than the implementation supports.  Lisp
code shares this dubious distinction with all other languages, of
course, so it is not fundamentally at fault.

> Like I said, all that is missing is the metaphor.  The
> best I have been able to come up with is the idea of pipes.  Anyone
> else have any better ideas?

Functions are a better idea.  Lisp, Scheme -- heck, even Logo --
present a fundamental improvement over pipes.  If a GUI permits the
implementation of comprehensible control for "hairy" structures, then
I will enthusiastically include it in my own toolbox.

Jim McCauley, Learning Products Engineer    **   I do not speak for   **
(that means that I write documentation)     ** Hewlett-Packard in any **
jem@cup.hp.com                              **   official capacity.   **