home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!gatech!emory!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!fj05+
- From: fj05+@andrew.cmu.edu (Faisal Nameer Jawdat)
- Newsgroups: comp.sys.mac.misc
- Subject: Re: MACS COST TOO MUCH (NOT!)
- Message-ID: <4efbJrm00WB28QiWRK@andrew.cmu.edu>
- Date: 9 Sep 92 14:06:47 GMT
- 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
- Organization: Sophomore, Physics, Carnegie Mellon, Pittsburgh, PA
- Lines: 80
- In-Reply-To: <5963.2aae0111@hayes.com>
-
- bcoleman@hayes.com (Bill Coleman) writes:
- a lot of stuff, some of which was dead center correct (copying large
- numbers or files, etc.) some of which was off - rememberring the name
- of a file versus finding it on a desktop - this was dicussed on the
- NeXT groups a while back, and the point was made that apple's studies
- were done on novices - macs are perfect for new users, but i know
- where most of my apps are on unix and on the mac, and i use a lot of
- them quite often, and to put 45 icons on the desktop makes things even
- worse than they already are - on the other hand a path ability would
- be perfect - but i test very high on quick associative recognition -
- whereas most non hacker types don't test as high on similar tasks when
- using computers because of negative blocking
-
- pullright menus make things even worse - but that's an implementation
- and not a philosophical question
-
- however : here is where he gets to the point:
- >
- > A simple example. A better case for CLIs might be made by looking at the
- > power of the Unix shell -- which allows complex graphs of applications to
- > be linked together. But the implication of this "piping" is that all data
- > is represented by ASCII text files. Sadly, very little data is ASCII text
- > in a graphical machine. So there's currently no equivalent for Unix pipes
- > in a graphical environment.
- >
- > The singular advantage CLIs might hold over GUIs is the ease of translation of
- > steps into a canonical notation. A CLI script is merely the concatenation of
- > several individual CLI commands. No equivalent yet exists for GUIs.
- >
- > Were breaking ground here. AppleScript promises to erase some of this
- > "advantage". Frontier has already automated many of these things. Note that
- > while Frontier sales are solid, they haven't exactly taken the market
- > by storm.
-
- this is why i bought a mac instead of a 486 to run os/2 or unix
- (maybe NT? - do i have to?) on - applescript may make up for the one
- major thing both dos, unix, and os/2 have on it: batch files. - also
- note that os/2 rexx lets you do apple eventish things...
- but apple script still won't let me do something like:
- finger -p fj05@andrew.cmu.edu &
- which fingers me without showing my plan ( i can remember that very
- quickly, but i think ahead of my typing, which is 52wpm counting
- errors - it also lets me do something else while i wait for it to
- load) - to finger from my mac i have to start the finger program, wait
- for it to load, wait type in hostname, tab, type in userid, and then
- i can go on to other things - this also involves a fair amount of
- mousing around
-
- the inability to pass data in and out of programs is one of the mac's
- major shortcomings ( maybe i can have programs output their info in
- discreet file packets, and just stack a whole bunch of drag and drop
- icons on top of each other ? oh well...) but if programs support apple
- events, then it should be trivial to have a script that opens a
- program, sets all the parameters, runs a computation, then outputs to
- a defined file, opens another app to look at said file - you could
- even have the apple script open up a dialog box on startup to ask what
- file you want final output to be called.
-
- gui's are better than cli's because they offer better multitasking
- capabilities - but they don't necessarily provide a faster operating
- environment, and so far, have much more limited data manipulation
- outside the scope of each individual program.
-
- > Perhaps the answer lies in the users. Graphical interface users don't need
- > scripting. At least, they don't need it very often. When they do, they
- > either pony up for it, or they make do with what they have.
- >
- exactly - cli's are better for some, worse for others - faster for
- some, slower for others
- on unix systems, most of what is done is manipulation of data stored
- as text, but usually representing more than straight text - the
- interface is designed towards that goal
- on macs, most of what is done is graphical in nature, and the
- interface is designed for such work
- i wouldn't run a spreadsheet on a unixbox (NeXT's excluded) and i
- wouldn't do anything network oriented from a mac (per se - i'm using a
- terminal emulator on my mac to type this, but i'm doing it from a unix
- box)
- gear the tool to the task, and don't say it's better for everything:
- what's the best weapon?
-