Re: newbie questions about git design and features (some wrt hg)

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 31, 2007, 16:22 UTC
Message-ID: <Pine.LNX.4.64.0701310805500.3632@woody.linux-foundation.org>
In-Reply-To: <7vodofx06s.fsf@assigned-by-dhcp.cox.net>

On Tue, 30 Jan 2007, Junio C Hamano wrote:

Show 10 quoted lines

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> > 
> > But I'll admit - my main reason going with C is (a) it's what I know and 
> > (b) I absolutely _hate_ being constrained by the language. The great thing 
> > about C (still) is that you can do *anything* in it. You're literally 
> > limited by hardware, and by your own abilities. Nothing else.
> 
> Well, if you count "time" as part of your own ability then that
> is true.  Some things are too cumbersome and not performance
> critical enough to do in C.

Sure. I'd probably not do some graphical front-end in C - although some of the toolkits make that resonable too.

But even for "time", C actually does have a number of big advantages that some people often seem to overlook:

 - it has absolutely tons of infrastructure. Something like Perl comes 
   *close*, but in the end, even the Perl CPAN stuff is just a drop in the 
   bucket for what somebody programming in C has. Other scripting 
   languages? Outside of their specific things (ie the tcl/tk kind of 
   thing), they really have nothing.

 - perhaps even more importantly: there's a ton of clueful people who know 
   it. Maybe this stems from my personal blinders on what "competent" is 
   (and from just my sheltered life in general), but absolutely everybody 
   who is deeply competent will know C. Not everybody will want to program 
   in it, but they *all* know enough to be able to work with it.

The latter one is rather relevant for open source programming. Finding some really competent person who has written a library to do (say, purely hypothetically - NOT!) a clean and efficient "diff" implementation can be a huge deal. And you will find that using C.

So yeah, C is low-level. Yeah, you have to know how "pointers" work. And yeah, it takes effort especially to get started. But once you have gotten started, you realize that:

 - it may have been a lot more work to get over the hump, but once you 
   did, you can find people who can work with you and help you.

 - yeah, you didn't really want to work with people who didn't know how a 
   "pointer to a function returning a const pointer" really works.

I agree that C is a really hard language for "prototyping". And yes, I'll also agree that probably 95% of all programming is really about prototyping. Make something that works, and move on. In that environment, C is simply wrong.

But in a real core infrastructure environment, I'd say that almost anything *but* C (or "fairly similar" language) tends to be a mistake.

So I personally tend to always work on that infrastructure thing, which is why I love C. If it's not "core enough" that C is the proper language, I'm probably simply not interested.

And yeah, it will change. I realize that. My bet is that C will remain as the default "system language" for at least another decade.

Of course, is an SCM "core enough"? Some parts definitely are. The actual low-level diff generation fairly obviously is. Is revision walking? Per-file operations? hg and git disagree about that decision.

		Linus