home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / mac / misc / 16282 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  4.9 KB

  1. Path: sparky!uunet!gatech!emory!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!fj05+
  2. From: fj05+@andrew.cmu.edu (Faisal Nameer Jawdat)
  3. Newsgroups: comp.sys.mac.misc
  4. Subject: Re: MACS COST TOO MUCH (NOT!)
  5. Message-ID: <4efbJrm00WB28QiWRK@andrew.cmu.edu>
  6. Date: 9 Sep 92 14:06:47 GMT
  7. References: <ewright.714687708@convex.convex.com> <92239     <ewright.714845483@convex.convex.com> <1992Aug27.202129.12780@CS.ORST.EDU>     <ewright.714954330@convex.convex.com> <92241.112023ASI509@DJUKFA11.BITNET>    <la4tfoINN43d@appserv.Eng.Sun.COM> <922 <ajross.7
  8. Organization: Sophomore, Physics, Carnegie Mellon, Pittsburgh, PA
  9. Lines: 80
  10. In-Reply-To: <5963.2aae0111@hayes.com>
  11.  
  12. bcoleman@hayes.com (Bill Coleman) writes:
  13. a lot of stuff, some of which was dead center correct (copying large
  14. numbers or files, etc.) some of which was off - rememberring the name
  15. of a file versus finding it on a desktop - this was dicussed on the
  16. NeXT groups a while back, and the point was made that apple's studies
  17. were done on novices - macs are perfect for new users, but i know
  18. where most of my apps are on unix and on the mac, and i use a lot of
  19. them quite often, and to put 45 icons on the desktop makes things even
  20. worse than they already are - on the other hand a path ability would
  21. be perfect - but i test very high on quick associative recognition -
  22. whereas most non hacker types don't test as high on similar tasks when
  23. using computers because of negative blocking
  24.  
  25. pullright menus make things even worse - but that's an implementation
  26. and not a philosophical question
  27.  
  28. however : here is where he gets to the point:
  29. > A simple example. A better case for CLIs might be made by looking at the
  30. > power of the Unix shell -- which allows complex graphs of applications to
  31. > be linked together. But the implication of this "piping" is that all data
  32. > is represented by ASCII text files. Sadly, very little data is ASCII text
  33. > in a graphical machine. So there's currently no equivalent for Unix pipes
  34. > in a graphical environment.
  35. > The singular advantage CLIs might hold over GUIs is the ease of translation of
  36. > steps into a canonical notation. A CLI script is merely the concatenation of
  37. > several individual CLI commands. No equivalent yet exists for GUIs.
  38. > Were breaking ground here. AppleScript promises to erase some of this 
  39. > "advantage". Frontier has already automated many of these things. Note that
  40. > while Frontier sales are solid, they haven't exactly taken the market
  41. > by storm.
  42.  
  43. this is  why i bought a mac instead of a 486 to run os/2 or unix
  44. (maybe NT? - do i have to?) on - applescript may make up for the one
  45. major thing both dos, unix, and os/2 have on it: batch files. - also
  46. note that os/2 rexx lets you do apple eventish things...
  47. but apple script still won't let me do something like:
  48. finger -p fj05@andrew.cmu.edu &
  49. which fingers me without showing my plan ( i can remember that very
  50. quickly, but i think ahead of my typing, which is 52wpm counting
  51. errors - it also lets me do something else while i wait for it to
  52. load) - to finger from my mac i have to start the finger program, wait
  53. for it to load, wait type in hostname, tab, type in userid, and then
  54. i can go on to other things - this also involves a fair amount of
  55. mousing around
  56.  
  57. the inability to pass data in and out of programs is one of the mac's
  58. major shortcomings ( maybe i can have programs output their info in
  59. discreet file packets, and just stack a whole bunch of drag and drop
  60. icons on top of each other ? oh well...) but if programs support apple
  61. events, then it should be trivial to have a script that opens a
  62. program, sets all the parameters, runs a computation, then outputs to
  63. a defined file, opens another app to look at said file - you could
  64. even have the apple script open up a dialog box on startup to ask what
  65. file you want final output to be called.
  66.  
  67. gui's are better than cli's because they offer better multitasking
  68. capabilities - but they don't necessarily provide a faster operating
  69. environment, and so far, have much more limited data manipulation
  70. outside the scope of each individual program.
  71.  
  72. > Perhaps the answer lies in the users. Graphical interface users don't need
  73. > scripting. At least, they don't need it very often. When they do, they 
  74. > either pony up for it, or they make do with what they have.
  75. exactly - cli's are better for some, worse for others - faster for
  76. some, slower for others
  77. on unix systems, most of what is done is manipulation of data stored
  78. as text, but usually representing more than straight text - the
  79. interface is designed towards that goal
  80. on macs, most of what is done is graphical in nature, and the
  81. interface is designed for such work
  82. i wouldn't run a spreadsheet on a unixbox (NeXT's excluded) and i
  83. wouldn't do anything network oriented from a mac (per se - i'm using a
  84. terminal emulator on my mac to type this, but i'm doing it from a unix
  85. box)
  86. gear the tool to the task, and don't say it's better for everything:
  87. what's the best weapon?
  88.