On Sun, Nov 25, 2012 at 5:44 PM, Michael Haggerty <mhag...@alum.mit.edu> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to