Re: [Gnu-arch-users] empty commits, wrappers, and version control frawemork

[James Blackwell]

David Allouche: 
>     Currently, a lot of convenience features need to be built into tla
>     because there is no way to implement them with decent perfomance on
>     top of the stateless CLI. For example, "tla replay" is getting a
>     heck lot of options and understanding how they relate and interact
>     is getting tricky.
>
>     The wrappers/front-ends are limited because they can only use the
>     CLI interface, and that makes them very wasteful. Something closer
>     to what they need, and not quite painful as implementing libtla.so,
>     would be "shell bindings to libtla". That might be implemented as a
>     butt-simple REPL, usable as a coprocess, which gives access to the
>     libtla features, and would allow reusing pfs connections and other
>     expensive resources. It seems that Christion Thäther has something
>     like that in mind.
>
>     It's getting time to start saying "no" to new convenience features
>     into tla and push people towards aba, raw (the python shell from Rob
>     Weir, soon to be released) and mala (the macro language from
>     Christian Thäther, still "almost vapor" according to the author).

This may be where we part ways.

I see tla itself as the one place where we have a guarantee of some sort
of consistancy of interface across heterogenous machines. Aba may be on
one machine, raw on another and mala on yet another. However, no matter
where I go, tla will be there. 

As such, arch should have a reasonable interface for performing
work. That way, no matter what machine I'm on, not matter what shell
extension that root on that machine happens to prefer, I am able to
continue on in my work, because I know how to use arch directly.

Personally, I think these extensions are a mistake, because there are
now five (or three, or twelve or whatever you like) different ways for
people to express a solution to solve a problem. 

You ever watch a linux channel? Even though everybody is running the
same kernel (for all effective purposes) and the same gnu operating
system, people have difficulty assisting one another. Debian users are
powerless explaining to a Redhat user how to install software, Redhat
users have to surmount minor configuration changes with gentoo users, so
forth and so on. Its a mess. 

>     That's an executive management issue: unless Tom takes a clear
>     position in that direction, pressure to make tla more and more
>     bloated and complicated is going to increase with the popularity of
>     Arch.

I've developed a dislike for the word "bloated". First off, this term is
a qualitive one. Second, even worse, its a relative one. Third, its been
abused so frequently, the word has lost what little meaning it had in
the first place. Some people even automatically name any tool built with 
i10n "bloated" because everybody should speak english anyways!

Once upon a time, bloat meant something like: 

  software bloat

          <jargon, abuse> The result of adding new features to a program
          or system to the point where the benefit of the new features
          is outweighed by the extra resources consumed ({RAM}, disk
          space or performance) and complexity of use.  Software bloat
          is an instance of Parkinson's Law: resource requirements
          expand to consume the resources available.  Causes of software
          bloat include {second-system effect} and {creeping
          featuritis}.  Commonly cited examples include Unix's "{ls}(1)"
          command, the {X Window System}, {BSD}, {Missed'em-five},
          {OS/2} and any {Microsoft} product.
                -The Free On-line Dictionary of Computing

Then, bloat was defined by journalists as 'The increase of unnecessary
features in order to justify new products and enhance sales'

Now, bloat seems to mean 'Any feature that I don't personally use'

The word "bloat" has become a joke. The addition of useful commands, and
a useful interface (within context) is a basic requirement of software.

Two long-forgotten, simple concepts have been lost, but need to be
rescuititated. Since nobody else seems to have claimed them, I'll define
these here and now as "Blackwell's laws"

     1. A direct relationship exists between the complexity of a problem
        and its solution.

     2. A direct relationship exists between the size of a solution and 
        its complexity.

Revision control is not a simple problem. As all know, an implementation
of revision control is a difficult, complex task. By invoking my two new
laws, we can surmise that arch, when fully complete, will be both
complex and large.

>     Eventually, probably for tla2, the CLI should be drastically cut
>     down and limited to a low-level toolbox for use with scripts. When
>     that happens, the end-user tools will have be already mature, so
>     something has to be done long before to stimulate their development.

Somebody, I think it was Einstein, once wrote "Make things as simple as
possible, but no simpler". If we follow this dictate, we should make
arch simple, but not so simple that we screw it up.

If we strip away from arch one of its basic components -- the interface,
that I personally feel that we've abandoned Einstein's reasoning and
we've made the solution *too* simple. 

> In a nutshell:
>
>     Front-ends suck because they cannot reuse expensive resources
>     created internally within tla, and unless that's fixed, the only way
>     to do complex things with acceptable performance is to add cruft to
>     tla.
>
>     Tla is trying to be the "low-level version control framework" and
>     the "standard version control CLI" at the same time. These
>     objectives have conflicting constraints, and unless the direction is
>     changed it is doomed not to be very good at either.

In all fairness, this is the way rcs works, scs works, cvs works,
subversion works, bitkeeper works, all of them works. 

Just like arch, they're all command line tools. 

Somewhere, along the line, we've built this misconception that command
line tools shouldn't have an interface. That just doesn't make sense to me!

> Cheers, have a nice sunday.

Hey! You too! 

-- 
James Blackwell          Please do not send me carbon copies of mailing
Smile more!              list posts. Such mail is unsolicited. Thank you!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400