[Gnu-arch-users] Low level vs. high level UI

[Pierce T . Wetter III]

> >  Question:
> >
> >    Why is this three commands? Why not one?
>
> Because this is only one way to arrange those three commands.
> Sometimes you tag without the other steps, sometimes you cacherev
> without the other steps.
>
> I've come to like Tom's algebraic analogy of "basis set spanning
> the space"  here.
>
> You're asking something akin to "why doesn't a typewriter just
> have keys for each word?  Why do you have to put all these dang
> letters together every time?"

 Except when I go to McDonalds, they have a keyboard with a key labeled
 "cheeseburger". There's a threshold where it makes sense to group 
low-level
 API into high-level API, especially if the high-level API can map 
directly
 onto a users task. In the case of McDonalds, having a "cheeseburger" 
button maps directly onto "the user ordered a cheeseburger".

 Taken to the other extreme, why have a keyboard at all? Why not just 
have a two keys, one that says 0 and one that says 1?

 Miles makes my point:

> Actually I usually use a script called `tla-fork' in my tla-tools 
> package,
> which is one command.  :-)

  It's been really apparent to me that while arch is pretty cool, its 
being implemented by kernel types. Which means a:

   "basis set spanning the space" user interface

  That is, everything consists of these low level commands that are 
then "assembled" as needed. However, low level commands are not 
necessarily more convenient. As a consequence, people keep writing 
scripts to automate things. However, if people have to write scripts to 
get their work done, then that implies a certain amount of failure of 
the UI as implemented to date, and lots of cruft like -S on some 
commands (but not others...)

 In order for arch to be accepted more widely, it has to have a much 
smaller learning curve. The easiest way to do that is to have some 
high-level commands that do the main tasks users actually do, with the 
low-level commands left for the special cases. Off the top of my head, 
my main tasks with arch would be:

   bootstrap regex (import the current directory tree into arch,
                    with the understanding that directories that
                    match regex (i.e. "Makefile") are sub-projects
                    saves all those "tla add *.c" commands you have to 
do...
                    )
   get     (as it currently works)
   update  (as it currently works)
   commit  (as it currently works)
   branch  new_name  [ from patch]
         (takes current set of source off in new direction forming 
branches
          as needed)
   join (opposite of branch, merges branch in current directory to 
ancestor)
   branch-update (grabs changes since branch from ancestor)
   grab-changes (star-merge basically, it grabs changes from elsewhere)

   Most of the details of how those above tasks would be accomplished 
aren't
   really important for a new user to know, so the details of whether 
that
   creates a new archive, makes new entries in the old archive, or 
whatever
   is kind of moot.

   And I would have the possibility of write-through mirrors, since 
everyone
   seems to make local mirrors of remote archive, and then has to do
   star-merges to integrate everything.


   tla is already evolving in that direction to some extent I notice, 
since I've been successful in leaving off bits of commands from the 
tutorial here and there, and things mostly happen "the right way". Like 
you can almost always leave off the version and patch spec, though not 
consistently. You can always leave off the category--branch--version 
spec if your current working directory is working source, etc.

  Anyways, high-level UI: Easy to start.
           low-level UI: Necessary for that last 10% of cases.

 Pierce