[tahoe-dev] barriers to using tahoe
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.
- 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
> > it.
> > It's not that the average user is stupid or incapable. It's just that
> > 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
> 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
> do mail merges -- even wacky, complex ones resulting in tens of thousands
> 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
> 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
> 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
> of cases, what people do with it would be recognizable to us as
> 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
> 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
> 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
> 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:
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tahoe-dev