home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / mac / misc / 13641 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  4.9 KB
  1. From: jem@hpcupt3.cup.hp.com (Jim McCauley)
  2. Date: Wed, 22 Jul 1992 19:12:44 GMT
  3. Subject: Re: Re: CLIs that teach; GUIs that don'ty
  4. Message-ID: <100760002@hpcupt3.cup.hp.com>
  5. Organization: Hewlett Packard, Cupertino
  6. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!hpscdc!hplextra!hpcc05!hpcuhb!hpcupt3!jem
  7. Newsgroups: comp.sys.mac.misc
  8. References: <1992Jul20.120019.73@physc1.byu.edu>
  9. Lines: 100
  10.  
  11. Clark Goble writes:
  12.  
  13. > But
  14. > the Lisp like programming you gave still causes a few problems, unless
  15. > you use it consistantly.
  16.  
  17. Inconsistent use of any programmable interface is hazardous, to say
  18. the least.
  19.  
  20. > If you have a good metaphor (data in a pipe)
  21. > then it is easy for the user to quickly do things.
  22.  
  23. The Lisp metaphor is quite simple: a function evaluates its arguments
  24. and passes the results as an argument to a successor function.  I
  25. taught this notion to elementary-school children through the use of
  26. the Lisp-like Logo language (and simpler terminology!), and they
  27. grasped it without difficulty.  The prefix notation of Lisp is no
  28. challenge to learners if it is introduced in a reasonable way.
  29.  
  30. > The problem with
  31. > most CLI is that there is no metaphor at all.  I suppose it is suppose
  32. > to be 'English like language' (the catch phrase from a few years back).
  33. > But the most English like langauge I have used is Hypertalk and I still
  34. > hate it.
  35.  
  36. English is a wonderful language for people and a terrible one for
  37. computers.  Functional languages are reasonably comprehensible to both
  38. parties.
  39.  
  40. > Yes.  And those who want to know about the innards tend to use their
  41. > computer more efficiently.  It is like a car.  If you know how it
  42. > works, you tend to drive better.
  43.  
  44. Well, maybe.  More to the point, if you understand something about the
  45. engine, and you see the oil-level warning light come on, you'll stop
  46. the car immediately because of your understanding.  You could be
  47. taught explicitly to "stop the car when that light comes on," but your
  48. relationship with the automobile is then fundamentally different.
  49.  
  50. > But many people want a computer to
  51. > be an invisible tool.
  52.  
  53. It is worth pondering what this "invisibility" costs.  One can argue
  54. that freeing the user from any obligation to understand his computer
  55. allows him to concentrate on other tasks.  But consider the insidious,
  56. ubiquitous and progressive "dumbing-down" of the user's technical
  57. capacity and the consequences of the sequestering of computer
  58. knowledge to an expert elite.  The computers are out on the people's
  59. desks, but the expertise is somewhere behind glass walls.  This is not
  60. what the personal computer "revolution" was all about.
  61.  
  62. > Doing the act should almost be unconcious.
  63. > 
  64. > That is always my test of good mac software.  Can I do it without thinking
  65. > much beyond what I want to accomplish.
  66.  
  67. Are users limited in any substantial way if they become expert in the
  68. use of tools, but they remain ignorant of the nature of their tools?
  69. That is the question of this age, and our fate is tied to it.
  70.  
  71. > And in a real sense Apple events are more
  72. > powerful than anything under UNIX.  Applications become the programming
  73. > language.
  74.  
  75. I must investigate Apple Events.  I suspect that they owe something to
  76. the "hairy control structures" that Carl Hewitt investigated for the
  77. Actor language in the 1970s.  Just as the classic Lisp paradigm of
  78. "multiple inputs/one output" transcends the one-dimensional nature of
  79. the Unix pipe, "hairy" control structures move beyond Lisp to allow
  80. reasonable structuring of multiple (even conditional) outputs to a
  81. variety of receiving functions.  User-level representation of such
  82. structures and communication channels in any interface (character or
  83. bitmapped) remains a challenging problem in cognitive science.
  84.  
  85. > Lisp has its power, the once again the metaphor is poor.
  86.  
  87. Actually, the problem is instructional, not cognitive.  Lisp is so
  88. very simple -- it's usually just not taught simply.
  89.  
  90. > Try reading a complex Lisp program and figuring out what you did.
  91. > It's fine for small things.  But get to big....
  92.  
  93. Solution: don't write big functions.  Lisp programs that are in fact
  94. arcane usually owe their opacity to the programmer's attempt to
  95. achieve higher performance than the implementation supports.  Lisp
  96. code shares this dubious distinction with all other languages, of
  97. course, so it is not fundamentally at fault.
  98.  
  99. > Like I said, all that is missing is the metaphor.  The
  100. > best I have been able to come up with is the idea of pipes.  Anyone
  101. > else have any better ideas?
  102.  
  103. Functions are a better idea.  Lisp, Scheme -- heck, even Logo --
  104. present a fundamental improvement over pipes.  If a GUI permits the
  105. implementation of comprehensible control for "hairy" structures, then
  106. I will enthusiastically include it in my own toolbox.
  107.  
  108. Jim McCauley, Learning Products Engineer    **   I do not speak for   **
  109. (that means that I write documentation)     ** Hewlett-Packard in any **
  110. jem@cup.hp.com                              **   official capacity.   **
  111.