On Sun, Nov 25, 2012 at 5:44 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > On the contrary, there is *constant* traffic on the mailing list about > incompatibilities between different shell implementations (sh, dash, > bash, etc), not to mention those in other utilities (sed, grep, etc) > that one is forced to work with in shell scripts. Compatibility is a > *huge* pain when developing shell code for git. The fact that users > typically don't encounter such problems is due to the hard work of POSIX > lawyers on the mailing list correcting the compatibility errors of > mortal programmers. I think we still are in the process of moving away from shell-based commands (not the shell interface), just not enough man power to do it fast. The only shell-based command with active development is git-submodule. So most shell PITA is in the test suite. > The most important issues to consider when imagining a future with a > hybrid of code in C and some scripting language "X" are: > > * Portability: is "X" available on all platforms targeted by git, in > usable and mutually-compatible versions? > > * Startup time: Is the time to start the "X" interpreter prohibitive? > (On my computer, "python -c pass", which starts the Python > interpreter and does nothing, takes about 24ms.) This overhead would > be incurred by every command that is not pure C. > > * Should the scripting language access the C functionality only by > calling pure-C executables or by dynamically or statically linking to > a binary module interface? If the former, then the granularity of > interactions between "X" and C is necessarily coarse, and "X" cannot > be used to implement anything but the outermost layer of > functionality. If the latter, then the way would be clear to > implement much more of git in "X" (and lua would also be worth > considering). > > * Learning curve for developers: how difficult is it for a typical git > developer to become conversant with "X", considering both (1) how > likely is it that the typical git developer already knows "X" and > (2) how straightforward and predictable is the language "X"? > In this category I think that Python has a huge advantage over > Perl, though certainly opinions will differ and Ruby would also be > a contender. * We might also need an embedded language variant, like Jeff's lua experiment. I'd be nice if "X" can also take this role. -- Duy -- 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