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

[Aaron Bentley]

On Wed, 2004-02-25 at 16:35, Pierce T. Wetter III wrote: 

> > It says "Use aba command -h for help on `command', or aba help command
> > for detailed help" at the bottom of "aba help" output.  But it's just a
> > frill-- aba command -H still works too.
> 
>   Sure, but README doesn't mention any of that...
> 
>   Really, you could bootstrap some documentation by just dumping aba 
> help, and aba help command for each of the aba comands to a file.

The aba command -H output is meant to be the authoritative help.  In
fact, I use "aba help --ext" to generate part of the aba web page.  I'd
rather improve that documentation than produce another set.  A second
set of documentation would just get out-of-sync fast. 

> >
> > I prefer easy interfaces, not simple ones.  For example, I use vim.  
> > And
> > I can use aba exactly the way I use tla.
> 
>    The difference between an easy interface and a simple one? I'm not 
> sure I understand the distinction? I prefer levels of interfaces 
> myself.

vi is a program that is hard to learn (not simple), but easy to use once
you do.  That's the kind of thing I mean. 

> > My view is that gradual evolution is a more certain way of generating a
> > set of useful commands than high-level design.
> 
>    Both have their place. I think its sometimes good to sit down and 
> think:
> 
>     Ok, what do I do all the time in arch?
>     How could that be more automatic?

My objective with aba is to lower the barrier to entry, so that the
first time you think "I do this a lot", you go and write an aba command.

> > I agree that tla's large command set represents a fairly high barrier 
> > to
> > entry.  On the other hand, I only use about 7 commands 95% of the time.
> 
>   Ah, what are the 7 commands you use. 
tla update, 
aba diff [tla changes --diffs], 
aba elog [$EDITOR $(tla make-log)], 
tla commit, 
aba merge [tla star-merge $(cat $(tla tree-root)/++merge-source))], 
tla archive-mirror, 
aba branch-this. 


> >>    aba suggestions:
> >>
> >>    have a register-archive that both registered the archive, and built
> >> an alias:
> >>
> > that
> > would not be useful for me.  But if you'd like to write it,
> > contributions are always welcome.
> 
>    If I knew arch a little better, I would...

I think it's just tla register-archive $1 $2; aba alias $3=$1

> >>   In the big picture, aliases are a general high-level facility so 
> >> that
> >> aba users can work with much shorter names. I would think that aliases
> >> should be names that they tend to create as they go along with other
> >> aba commands like "branch-this" and "tag-this".
> >
> > Oh, I almost always branch into the default archive.  So I haven't seen
> > the need for it.  How would you use it?
> 
>    Well, like if I wanted a branch:
> 
>     projects--fixingpunctuation--1.2 in archive:
 
Which archive? You can't branch into jblack's archive, only he can. 

>    aba branch-this fixingpunctuation
> 
>    would let you use
> 
>   aba get ^fixingpunctuation
> 
>   because that would expand to:
> 
>   tla get address@hidden/projects--fixingpunctuation--1.2
> 
>   Does that make a little more sense?

Not really.  Because if it's your default archive, you can use 
tla get projects--fixingpunctuation.  And if it's not your archive, you
can't branch into it at all.  The only case I can see for it is for a
non-default archive that you own.

Aaron 

-- 
Aaron Bentley
Director of Technology
PanoMetrics, Inc.