Re: Libification project (SoC)

On Sun, 18 Mar 2007, Theodore Tso wrote:

I don't think that's a good argument, ESPECIALLY when coming from somebody from MIT.

Berkeley may have gotten it "horribly wrong", but the fact is, BSD kicked ass and took over the world, in a way that nothing comparable I know of from MIT ever did. Exactly *because* the BSD people didn't try to make it perfect, but made things "small and easy to *implement*".

(I would not say "small and beautiful". "Beauty" had nothing to do with it. "simple" had. And unlike beauty, simplicity really *is* more than skin deep, and is a fundamentally good design).

I'm a *huge* believer in "Worse is Better" (for people who don't know it, just google for that phrase, with the quotes around it).

In fact, I'd argue that the reason git kicks ass is exactly that "Worse is Better" design: you need to have a few conceptual (good) ideas to base your design off on, but given those good ideas, it's more important that things _work_well_in_practice_ than some "wouldn't it be better.." kind of mentality.

The "paying the price ever since" argument is bogus. If you get to that point, you've by definition *already*won*!

Here's the real world according to Linus:
 1) everybody makes mistakes
 2) only the winners "pay the price" of those mistakes ever since, since 
    the losers will not be around to pay it, and the winners will have 
    made mistakes too (see #1)
 3) the more complex and subtle you make the interfaces, the more mistakes 
    you'll make, AND the less likely you are to be a winner anyway, since 
    you'll have problems implementing it *and* it will probably be subtle 
    to use too!

So the motto should always be: "Just Do It!", and screw worrying about paying the price. You *want* to have to pay the price. It's the best thing that can ever happen to you. And you want to have to start paying the price as early as possible - because that not only means that you won, it also means that you'll now be learning from your mistakes instead of trying to anticipate them, and I will *guarantee* that learnign from mistakes is going to be a lot more productive than trying to worry about them up-front.

I'd personally strongly vote for a "simple library" interface as a first cut.

And yes, if that means supporting two versions, I think it's better. You can easily have "libgit-simple.a" for trivial non-threaded accesses with out-of-memory conditions causing the process to die. That really *is* a very useful schenario, as shown by the fact that *every*single*core*git program has been happy with it.

Claiming that you need a complicated interface in the face of the *proof* that git itself dosn't need that complicated an interface is to me a bit disingenious.

Yes, *some* people will want a thread-safe one. But we're not talking something like libc here, where the library is so fundamental that it needs to be acceptable for everybody. It's perfectly possible to have a "libgit-simple.a" that is good for 99% of all uses, and that is simple to use, and less bug-prone simply because is is *simpler* (not just for users, but as an implementation).

And then for the small small minority of programs that want something fancier, do a "libgit-complicated.a" library. IF you ever get it working and complete, you can always then implement "libgit-simple" in terms of the complicated version.

  Is it