Re: Libification project (SoC)

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sun, 18 Mar 2007, Theodore Tso wrote:
> 
> Berkely got it horribly wrong when it tried to start with the "small
> and beautiful" functions that were non-reentrant, and we've been
> paying the price ever since.

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.

> Do we really want to support two versions of the API forever?

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 
> really that hard to support a reentrant API from the beginning?  I'd 
> submit the answer to these two questions are no, and no, respectively.
> 
> 						- Ted
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>