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

Linus Torvalds [off-list ref] writes:

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.

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