Re: [PATCH] Make "git reset" a builtin. (incomplete)

From: David Kastrup <dak@gnu.org>
Date: Aug 22, 2007, 19:36 UTC
Message-ID: <86absjcqfq.fsf@lola.quinscape.zz>
In-Reply-To: <alpine.LFD.0.999.0708221149440.30176@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 11 quoted lines

> So scripting languages are often good for *prototyping*, and a lot
> of people like scripting languages for that reason. But once
> something is already prototyped, and if somebody then rewrites it in
> C, all the advantages of a scripting language have already
> disappeared!
>
> I don't understand why people consider scripting languages (whether
> shell, perl, or anything else) "better" than C if there is an
> alternative. Once the C work has been done (and if you require C
> _anyway_ for other reasons, like git does), doing it in C is simply
> superior.

Actually, the same holds for assembly language vs C. Once the prototyping is over...

The main point is that with an evolving product, the prototyping never is over. And if the prototyping language is good enough, one never needs to spend the time to "implement properly" when one already has a working prototype. Instead one can build upon the prototype, which is actual progress. Emacs is an example: its bulk is written in Elisp. Would it be faster, smaller and more efficient when rewritten completely in C? Sure.

But it would stop being as hackable. And you could have the fun of searching for memory leaks and buffer overflows and crashes all the time with code you were just prototyping. With Elisp, you have a whole slew fewer ways to shoot yourself in the foot really hard. When only 5% of the code is C, only 5% can crash hard, leak memory and so on.

> Having tried to do internal scripting languages, I can say that it's
> just easier to do it in C once you get past the hump of getting it
> written in C in the first place.

But it is not "once" that you need to do this.  It is a permanent job.

Show 6 quoted lines

> So yes, we could just make the shell/etc from busybox _be_ the
> scripting language, but the fact is, that is *more* C code than just
> making the commands C code in the first place, and while a lot of
> the effort is already done for us, "busybox under windows" is
> actually likely to be more of a maintenance problem than "native git
> commands under windows" are.

Maintenance: yes.  Development: no.  If you want a product you do not
want to touch again, C is a good final choice.

> And LUA may be a nicer scriping thing than most, but you still end
> up having the impedance match, and quite frankly, I think we'd have
> much fewer problems with just rewriting all the remaining shell
> scripts in C, than to integrate LUA and write them in that.

Sure: if you are aiming for a job that gets finished and then no
longer touched.

Maybe something like Lua would be overkill for the amount of hacking to be expected: it would indeed ask for reimplementing existing stuff again. git-busybox would have the advantage of being able to jump-start the existing script base, while still obliterating the whole portability angle.

> (Quite frankly, havign looked at monotone development, I can say
> that we should avoid LUA and things like Boost like the plague. If
> it's not a library that has been around for ten years or more, it's
> not worth the headache).

Lua development was started in 1993.

Anyway, I don't see things as black&white as you do, but as long as nobody actually implements anything, the discussion is rather idle.

Lua would likely be more portable than git-busybox (and certainly much smaller), but then one would indeed have a non-trivial rewriting task. Anyway, I'll follow any git-busybox announcements. At the current point of time, it is probably the most advanced candidate for both retaining scripting and gaining portability.

-- 
David Kastrup