[tahoe-dev] barriers to using tahoe

Jody Harris imhavoc at gmail.com
Sat Feb 6 23:51:07 UTC 2010


I think we've moved into a 'religious wars' context.

To make any further progress in this discussion is going to require
face-to-face discussion over beer or coffee or something....

We're both making valid points, and it takes time to disentangle the various
elements. Call me if you're ever near Roswell, NM.

jody
----
- Think carefully.
- Contra mundum - "Against the world" (St. Athanasius)
- Credo ut intelliga - "I believe that I may know" (St. Augustin of Hippo)


On Sat, Feb 6, 2010 at 4:41 PM, Chris Palmer <chris at noncombatant.org> wrote:

> 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
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20100206/c6d23ef6/attachment.html>


More information about the tahoe-dev mailing list