gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: arch roadmap 1 (and "what's tom up to")


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: arch roadmap 1 (and "what's tom up to")
Date: Fri, 2 Jul 2004 10:23:14 -0700 (PDT)

    > From: "Pierce T.Wetter III" <address@hidden>

    >> You might not know that when Information Technology Center at CMU was
    >> working on the Andrew email program, towards the end of the lifetime
    >> of the Andrew project, they added a turing complete extension language
    >> to the email program (a Scheme dialect) --- alas, by that time, it was
    >> far too late to deploy much.

    >   That's exactly what I'm talking about. What I had read that they found 
    > was
    > that users didn't like the turing complete extension language. They 
    > liked
    > the sort of ad-hoc thing they had before, because they never got:

    >   "syntax error on line 30"

    >   It just did something weird instead. :-) So they screamed, and they put
    > the old config language back, not because of legacy files, but because 
    > it
    > was easier to use.

_Reconstruction_ from my memory suggests that what happened there was
this:

   1) The Scheme stuff in the mail program was done very late on,
      by one of the junior programmers.   Essentially, all of us
      junior programmers there were apprentices although I don't think
      any of us thought of ourselves that way at the time.

   2) At that time, the project was unofficially in a phase of 
      "graceful shutdown" -- grant renewals were no longer presumed
      and the emphasis for CMU was on stabilizing what was, by then,
      a system that every department and pretty much every member of
      campus depended on for day to day work.

So, yeah, if the choice was between "Hmm... work harder to make this
cool new thing friendlier" or "Eh.... back it off".... the latter
would have been the choice.

But you'd have to talk to the principles in the mail-system subproject
to get the definitive poop.


    >   That seems strange from a programming point of view, but for a user 
    > its much
    > easier to deal with:

    >   option.foo.bar = 30        (dumb parser, read first string, then = , 
    > assign to second string)

    >   then

    >   option(blah(blah))=30;       (note semicolon required, balanced 
    > paranteses, etc...)

Informally, people have studied what happens if you through a
non-programmer user at some rules for setting thing in a .emacs file
using lisp syntax.   The anecdotes are along the lines of user reports
like "Wow, this is actually the best editor-thingie I've ever used."

>From what I've seen, I'm very skeptical about a priori arguments that
this or that syntax is "too hard" or "too unfriendly".


    >   As programmers, compile time errors are much better then runtime 
    > errors (one thing that
    > bugs me about Python, for instance). For users, sometimes simple and 
    > stupid is often
    > better, because the user doesn't want to have to store in his brain ANY 
    > information
    > about how to write a config file. For instance, while I have written 
    > some complicated
    > makefiles, I actually can't at this moment remember how to write one. 
    > That information
    > is stored offline on some dead trees.

I think the deeper truth you are reflecting is that the user model for
a system has to be simple and clear for all definitions of user.

That _might_ mean "no compile-time errors" or it might mean
"compile-time errors with very clear messages" or something else
entirely.   There's few or no very simple rules about what will work
and what won't.


    >   When I worked at a video game company, one cool program we had was a 
    > "programming for
    > artists" tool. It basically knew enough about syntax so that it would 
    > only present enough
    > options to the artist at any moment so that the syntax was perfect. 
    > That is, if you had a
    > blank page, you could choose from a list of possible statements: 
    > assignment, if, while, for,
    > etc.

    > It was amazing some of the complex scripts these artists were able to 
    > produce when they
    > were presented with a small list of choices at each juncture. For 
    > instance, you were only
    > allowed to choose a variable if you'd already declared it, and if it 
    > was the right type, etc.

    > Now these are artists, so they're very right-brained, and not generally 
    > very verbal.

That's sounds very neat.

    > So anyways, I'm not sure that "turing complete" is better then "stupid".

I don't think it's a true dichotomy.  I think it's a spectrum and,
perhaps, the ideal is that user's be able to decide where on that
spectrum to place themselves.

-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]