home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / mac / misc / 13708 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  6.4 KB

  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!hamblin.math.byu.edu!yvax.byu.edu!physc1.byu.edu!goblec
  2. Newsgroups: comp.sys.mac.misc
  3. Subject: Re: Re: CLIs that teach; GUIs that don'ty
  4. Message-ID: <1992Jul23.180852.85@physc1.byu.edu>
  5. From: goblec@physc1.byu.edu
  6. Date: 23 Jul 92 18:08:52 -0600
  7. References: <1992Jul20.120019.73@physc1.byu.edu> <100760002@hpcupt3.cup.hp.com>
  8. Distribution: world
  9. Organization: Brigham Young University
  10. Lines: 118
  11.  
  12. In article <100760002@hpcupt3.cup.hp.com>, jem@hpcupt3.cup.hp.com (Jim McCauley) writes:
  13. > Clark Goble writes:
  14. >> But
  15. >> the Lisp like programming you gave still causes a few problems, unless
  16. >> you use it consistantly.
  17. > Inconsistent use of any programmable interface is hazardous, to say
  18. > the least.
  19.  
  20. Yes.  But a good Mac based CLI or script language would have to be such that
  21. people could use it without having to know it well.  The big advantage of a Mac
  22. is that I can use seldom used programs and still do what I want quicly and
  23. easily.  On my Sun I spend quite a few minutes figuring out how to make the
  24. find command do what I want, or write a script for awk etc.  The Sun has more
  25. power in many ways, and certainly more speed.  yet I find that it takes a
  26. fraction of the time to get things done on my Mac.  I think this extends to the
  27. CLI discussion.  Should you need to learn a langauge to make the computer do
  28. what you want?  Those who wish to can (C, Pascal, Forth, etc).
  29.  
  30. >> If you have a good metaphor (data in a pipe)
  31. >> then it is easy for the user to quickly do things.
  32. > The Lisp metaphor is quite simple: a function evaluates its arguments
  33. > and passes the results as an argument to a successor function.  I
  34. > taught this notion to elementary-school children through the use of
  35. > the Lisp-like Logo language (and simpler terminology!), and they
  36. > grasped it without difficulty.  The prefix notation of Lisp is no
  37. > challenge to learners if it is introduced in a reasonable way.
  38.  
  39. Relative to what?  C or Pascal?  I learned C in a day.   C++ took a little
  40. longer, but that was because you have to reorient your mind to object thinking.
  41. But no language is as easy to use as the finder, that I have seen.
  42. I'm not sure that functional metaphors are ideal for the script language., 
  43. This would be doubly true for Apple Events.  Yet, unless I am mistake I think
  44. this is more or less the idea behind Frontier.  (Never used it though)
  45. > English is a wonderful language for people and a terrible one for
  46. > computers.  Functional languages are reasonably comprehensible to both
  47. > parties.
  48. >
  49. Not necessarily.  Having TAed a Math Modeling class for people who had had
  50. Algebra, I can testify that the concept of a function is not intuitive to many,
  51. many people.  To people in the sciences it is obvious.  But most people are not
  52. only not in the sciences, but are paranoid about things relating to the
  53. sciences.  Remember, the Mac is the computer for the rest of us.  I agree that
  54. fucntions are great.  One reason why I use Unix and C.  But I know my Mom would
  55. freak out if she had to use the computer this way.
  56.  
  57. >> But many people want a computer to
  58. >> be an invisible tool.
  59. > It is worth pondering what this "invisibility" costs.  One can argue
  60. > that freeing the user from any obligation to understand his computer
  61. > allows him to concentrate on other tasks.  But consider the insidious,
  62. > ubiquitous and progressive "dumbing-down" of the user's technical
  63. > capacity and the consequences of the sequestering of computer
  64. > knowledge to an expert elite.  The computers are out on the people's
  65. > desks, but the expertise is somewhere behind glass walls.  This is not
  66. > what the personal computer "revolution" was all about.
  67.  
  68. In my experience this is the fundamental difference between PC users and MAc
  69. users and probably why they will never understand one an other.  Just look at
  70. the silly flame wars here.  I consider myself a technical user, but I love
  71. having the computer invisible.  Probably the closest I'll get to having a
  72. Zen-like experience.   (-:
  73. >> Doing the act should almost be unconcious.
  74. >> 
  75. >> That is always my test of good mac software.  Can I do it without thinking
  76. >> much beyond what I want to accomplish.
  77. > Are users limited in any substantial way if they become expert in the
  78. > use of tools, but they remain ignorant of the nature of their tools?
  79. > That is the question of this age, and our fate is tied to it.
  80. >
  81. I breath quite well without knowing the details of the breathing process.
  82. Likewise I plug things into wall sockets without needing to know about AC
  83. circuits.  Now I personally love to knwo these things.  It is the reason I went
  84. into Physics.  And I find that knowing helps me.  But is it necessary?  I do
  85. acknowledge though that many problems in our society are due to ignorance on
  86. the part of our populace.  The science is magic syndrom.  But I think knowing
  87. the details of the MacOS isn't required for computer literacy, any more than
  88. knowing Maxwell's laws is required to use a TV.
  89.  
  90.  
  91. >> And in a real sense Apple events are more
  92. >> powerful than anything under UNIX.  Applications become the programming
  93. >> language.
  94. > I must investigate Apple Events.  I suspect that they owe something to
  95. > the "hairy control structures" that Carl Hewitt investigated for the
  96. > Actor language in the 1970s.  Just as the classic Lisp paradigm of
  97. > "multiple inputs/one output" transcends the one-dimensional nature of
  98. > the Unix pipe, "hairy" control structures move beyond Lisp to allow
  99. > reasonable structuring of multiple (even conditional) outputs to a
  100. > variety of receiving functions.  User-level representation of such
  101. > structures and communication channels in any interface (character or
  102. > bitmapped) remains a challenging problem in cognitive science.
  103.  
  104. Yes.  I am just waiting to see how they are going to be controlled.  I have no
  105. problem with using them in a programming like language.  I jsut wish for Q&D
  106. tasks that my pipe idea or something bettert is also available.> 
  107. > Functions are a better idea.  Lisp, Scheme -- heck, even Logo --
  108. > present a fundamental improvement over pipes.  If a GUI permits the
  109. > implementation of comprehensible control for "hairy" structures, then
  110. > I will enthusiastically include it in my own toolbox.
  111.  
  112. Well I am not convinced that it is ideal for a CLI.  However you have intrigued
  113. me about LISP.  I must confess only a superficial knowledged of it.  And that
  114. was gained mainly in designing a metaphor for an other language.  But I am now
  115. looking into it again.  
  116.  
  117. Clark Goble
  118. goble@sofya.math.byu.edu
  119.  
  120.