[tahoe-dev] barriers to using tahoe

[Chris Palmer]

Jody Harris writes:

> Analogy: Linux command line.

Your analogies demonstrate my point, not yours, as I'll discuss below. :)

> It's there on every system, but the average user has no reason to ever see
> it.
> 
> It's not that the average user is stupid or incapable. It's just that they
> are not going to invest the time to learn and master it. If they decide
> to, it's readily available to them -- there are no artificial barriers.

Let's ask why. Why will people not invest the time to learn and master it?
Why do users have no reason to ever see it? It's not because the Linux
command line lacks the power to do what people want -- we know it does what
we want. And it's not because people don't need what the Unix shell
provides. Nor is it because people are dumb, ignorant, innocent, uncaring,
or whatever.

Consider sed and awk. Beautiful, powerful, general tools, right? And yet,
for some reason, people prefer to use the "mail merge" feature of MS Office
rather than a shell script you could gin up in a few minutes. Mail merge (in
which a document template's variables are filled in prepeatedly from a
sequence of records, like form an Access database or an Excel spreadsheet)
is just one of the many things sed and/or awk can do, but millions of people
do mail merges -- even wacky, complex ones resulting in tens of thousands of
print jobs -- all the time. This basic kind of programming is something
people want to do and can do, but they choose to use a different programming
environment than we do.

I argue they do so for good reason. Smart people who have an important job
to do (say, mailing out 10,000 form letters asking rich people for donations
to a children's hospital) use the tool that works and is quickly learnable
rather than spend hours poring over terse manuals to get the correct
invocation of sed (have fun with the subtleties of Unix shell quoting!).

For a more complicated example, consider what people do with Excel. In a lot
of cases, what people do with it would be recognizable to us as programming.
People spend a LOT of time in MBA school learning to program with Excel.
They first have to meet their calculus requirement (!). Why don't they use
awk, R, dc, and gnuplot? Excel is for people who are too smart to waste
their time learning crazy invocations that were correctly recognized as
kinky even back in the 70s.

I urge you all to spend some time with BBEdit, the Mac text editing system
that is strangely like a visually-learnable Unix shell environment. Why can
non-geeks use BBEdit but not Unix shell?

> Analogy: computers
>   Users don't have to understand how they work to make good use of them.

It is our job to make it possible for people to make good use of computers.
(I also add "safe use of computers".) If people can't use our creations, it
is our fault, not theirs. In fact software has no other purpose than meeting
peoples' needs.

> Not every functionality needs to be exposed through every interface. Most
> users are content that a task is completed per their expectations. Any
> further information essentially "breaks" the system for them. Too much
> information leads to mental buffer overflows.

I argue that rather than hiding information, we should seek designs that
require less abstraction and hiding, and yet still meet peoples' needs. We
could thereby build systems that are *even better* than BBEdit and Excel.

Layers of abstraction are necessary in computer system design. The task is
not to rationalize the ones we have, but to iterate ever closer to the right
abstractions in the right places at the right times.

"Those who don't understand Unix are doomed to reinvent it, poorly";
however, those who don't understand people's requirements are doomed to toil
too hard for too small an audience.

You may still choose to reside in the software ghetto, but do so knowingly,
like Milton Babbit chooses the music ghetto:

http://www.palestrant.com/babbitt.html