I see a more serious problem in the mac/unix OS debate,which I will go
into in some detail.
>but that Macintosh propogated the (IMHO)
>counterproductive idea that you shouldn't have to read any documentation to
>use a computer.
>Nobody ever wrote an operating system with the intention of
>making it hard for people to learn. They wrote them to be versatile and
>A chain saw is powerful too, but you need to learn a few things
>before you can use it.
AGAINST THE "BLACK AND DECKER" ARGUMENT
I've seen this argument, with the exact "power tool" analogy
often enough to give it a name. It goes as follows: Really
powerful things must have a lot of parts which must be understood for
safety. After all, cars that let you drive 180 mph require you to do
your own tuneups!. Users should expect that any powerful device (and
a computer program is a device like any other) will require you to
learn a lot of complex things to use it effectively. Things that are
easy to use can't be powerful.
It is not valid to compare an OS to a physical entity
like a car. A complex machine in the real world and a collection
of logical interactions programmed into a computer have vastly
different behavior in the hands of users. A computer program
is an arbitrary collection of ones and zeros that is the programmer's
concept of a particular machine. The connections between the symbols
comprising its algorithm and the symbols for controling it are
COMPLETELY ARBITRARY, and follow no laws except the whims of the
programmer. Any set of key presses can stand for any procession of
bit-flips. There is no reason to prefer function key f10 over f9
for saving a file, for example.
By contrast, real-world machines have real parts with real
connections, instead of symbols and symbols connecting them. As such,
real machines, even complex ones, have an internal consistency
that people can learn readily and don't forget. One can ride a bicycle,
without practice, many years after learning how. Can the same be said
for a code-driven OS? I think not.
The reason for this is that a computer program can be inconsistent
in a way a real object like a car never can. Saws may break, but they
don't "crash". The connections between parts of a program, or the
interactions between it and the user, don't have to make any deep sense
because one can "force" a particular set of relationships impossible
in the real world. This is done all the time in computer programming,
because simplifying the program often speeds it up. This is also called a
"clever hack". A real car, for example, allows you to adjust the seat
whether or not the motor is running. A efficiently simulated car, on
the other hand, might allow seat adjustment before starting its
simulated motor, since it was easier for the programmer to make it
this way. In short: what normally means simplicity and elegance to a
programmer will be difficult and obscure to a user.
An example: there is nothing about the task of saving a file
that connects it to any one key, picture of a disk onscreen, beep,
etc. Compare this to saving a book in a bookcase. The bookcase cannot
arbitrarily be replaced by a "symbol" to do this. That's why
its easier to save a book than save a file! A computer can
substitute any symbol for file saving, be it confusing or
enlightning. The choice of symbols for this will be the decision of
the programmer alone, since no real-world constraints bar their
I hope the above gives some idea of why its harder to use a computer
than to drive a car. An OS can be anything! Mac, unix, lisp OS--they're
all philosophies other people have invented for to structure our work.
But what does this have to do with mac vs/unix?
Currently, there are two models prevalent in computing. One is to
create a set of abstract concepts such as stacks, pointers, pipelines,
streams, threads, etc., relate them, and construct tasks like word processing
out of these basic concepts. These tools frequently don't correspond to
things you do in the real world (how often have you greped your car?).
All current OS systems have these as a base. In many OS systems, these
features are largely hidden from the user. In others (like unix) they
comprise the level at which the user interacts with the computer. The user
is expected to understand the philosophy behind them well enough to
translate their problem into the commands.
In order to do this, users have to memorize a large set of tinker-toy
set of interactions the programmer invented. This is not like learning
to drive a car. The commands have a huge arbitrary component to their
behavior. For example, it may be necessary to execute several of them in
a specific order. Usually, this order has nothing to do with the problem
being solved, and was imposed by the programmer to simplify and streamline
the OS. Since these commands do things with no counterpart in everyday
experience, and are inconsistent in their behavior, the user must fill
in all the exceptions to use, command ordering, etc. in their head. A compact,
elegant OS on the computer is complemented by a big untidy mess of rules
in the user's head. Most of the OS is actually in the user! To handle it
properly, the user must set up queues, batches, stacks, etc in their head,
and shuffles and poke the smaller passive portion on the computer. A less
than expert user, who has not reached this stage of computerizing their
thoughts, will be unaware of the huge number of unspoken conditions,
exceptions, etc., to use a tool in the OS, and will usually fail.
Take an OS where it is necessary to open a window, and then direct
data from a file into it. This is contrary to real-world experience.
To open a book, you don't have to prespecify the paper before reading
the text! So the user runs a little program in their head, specifying
the order of execution of the commands, remembering what has to come
before what. This is what I mean by most of the OS running in the
The shortcuts and inconsistencies in the logical structure are filled
in by the user's brain program. A super user who completely grasps this
system can of course ride it like a bucking bronco, and do things faster
than the rest of us. To such a user, anyone else who accomplishes a similar
task more slowly and without reading a manual will of course seem counter-
productive, whether or not they get their work done!
The logic of the typical OS (unix is hardly the worst at this, it
pales in comparsion to something like FORTH or PostScript) is contrary to
the associative memory we normally use to work. People simply don't think
in stacks, queues, pointers, modal programming, etc., etc. They are
hard to remember once learned. They are in fact so hard to learn that
they must be learned as an end in themselves(read:power users). The
"power tools", having arbitrary properties, don't provide the feedback
they would if they were actual tools.In order to remember them, the user
requires an emotional committment. To the extent to which the OS uses
tools that aren't anything like real-world tools, the commitment will
have to be all the greater.
Consider the "efficient" work of a power user. Looking at a screen nearly
blank but for a character or two in the left-hand corner, they proudly
punch a single "macro" key. The keypress initiates some extremely complex set of
operations with remarkable efficienty. I state this efficiency was actually
bought at huge cost. The user memorized the OS, and preran it in their heads,
then actualized it in the computer. This takes a lot of work, since
recent work in congitive science has demonstrated that the brain
does not operate like a computer executing programs. We don't use
pointers to remember, we find things by associative memory. We
don't build stacks or queues of significant size. These things must
be laboriously trained into our brains. I question the true efficiency
of such an approach.
Programmers and power users have totally forgotten the
struggle they had to learn those "simple 9-step proceedures" (an actual
quote)--it took YEARS,not a few days in a course.
They have been re-learning constantly, as even THEIR brains
cannot remember a large collection of logical operations executed in
a way contrary to day-to-day experience. Furthermore, since
they have to find ways to decompose problems like writing a letter into
the peculiar tools of their cherished system, they begin to see this
as the RIGHT way to think. And they want to convert the rest of us.
As such, power users and programmers are the worst judges of the value
of an OS to the vast majority of users. They want everyone to buy into
their philosophical framework for viewing reality, which is the OS
they constantly have to practice to use at all.
Thus, the resentment of users towards mastering a more powerful and
harder to use OS comes from more than complexity. After all,
people eagerly learn many hard things. I think the users can tell
at some level the things they are learning about the OS aren't
"truth", they're just the way the programmers decided to arrange
things, and as such learning them requires buying into their
An example: I know a mac user who 1) scanned playboy centerfolds into his
computer, 2) edited the resulting file with a drawing program, and 3)
printed it out on a color printer. He has gone so far into the world of
the OS that he must process real-world things according to its rules.
So much for the "power" OS..........
The alternate approach has been taken TO SOME EXTENT by the mac.
There is an attempt to make the available "tools" have some of the
behavior of real-world tools. This includes consistency in their operation,
even if a more efficient way might be devised for doing the task. The tools
can be used at any time, instead of requiring specific orders of execution.
The OS handles the logical inconsistencies which arise. It mimics the real
world to some extent, allowing users to transfer their extensive,
associative knowledge about the real world to using the computer.
Deleting a file becomes throwing it in a trash can, for example. This
doesn't require a window/trashcan GUI like the mac or windows--a notebook
or rolodex metaphor is just as servicable. The user sees the computer as
mimicing a reality they understand, instead of creating a sup