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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html