On Wed, 22 Aug 2007, David Kastrup wrote: > > > > What is wrong with going from shell to C? > > That it is not a script language where cause and effect of tying > simple functionality together is apparent, and easy to do. Why does it have to be a scripting language? "git reset" is a command, not a scripting language. We can still script git as much as we want, but the fewer dependencies we have on anything external, the better off we are. We ended up writing our own versions (or merging other peoples code) for things like appying patches, generating diffs, three-way merging etc, because not having external dependencies is *so* much more maintainable and portable that it's not even funny. Was it "simpler" to just depend on external things like GNU patch and diff? Yes. But it was strictly much worse to maintain, and it also limited us - thanks to integrating our own diff/merge/patch, we've been able to make them suit us much better. I'd love for every single shell-script in git core to be written in C, so that we can drop the dependency on shell *entirely*. I also dispute your "easy to do". Quite often, shell (or any scripting language) is actually much *more* complicated than C. Yes, the C code may be more lines (in this case, the shell script is 106 lines, and the C code was 216 lines), but from a maintenance standpoint, C has had *much* fewer problems than the shell script stuff has ever had! 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. > Red herring. The proposal was not to do nothing, but rather give git > a dedicated scripting language internal to it. Two suggestions of > mine with different advantages were git-busybox and Lua. 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. The "impedance match" problem between core code (which is inevtiably in C) and the interfaces the scripting language offers is invariably a nasty issue. 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. So if we have the choice, and somebody has written a git command in native C code, I think we should *always* take it. Just because it means that _eventually_ we can drop shell entirely, even if it would be a git internal busybox shell. 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. (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). Linus - 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
