On Sun, 25 Nov 2012, Eric S. Raymond wrote:
Michael Haggerty <mhag...@alum.mit.edu>:
There is, of course, the awkward issue of how/when to transition to
Python 3.x, which is *not* backwards compatible with Python 2.x. I
expect that when the time comes there will be volunteers (myself
included) willing to help adapt Python scripts to the new version, but
the problem shouldn't be minimized.
2to3 actually does a pretty good job. It doesn't reduce the
transition cost to zero, but I find it does reduce that cost to an
easily manageable level even on quite large codebases.
It would be insane to rewrite performance-critical C code in any
scripting language, but there is a huge penumbra of code that is not
performance critical and that mutates rapidly.
Indeed. In the git architecture there is a pretty clear dividing line -
to a first approximation, plumbing should remain C but porcelain should
probably not. (Not that I am advocating forcing such a move - but it would
be good to allow it to happen.)
The 80-20 rule (80% of the execution time is spent in 20% of the code)
helps us here. The *other* 80% of the code can move to a scripting
language with no significant performance loss. To find out what needs
to stay in C, run a profiler!
Remember that old code is tested code. The mere act of re-writing it from
scratch is likely to introduce new bugs due to 'simplifications' by the person
re-writing the code.
If a particular piece of code has a track record of being buggy, this may be
overwelmed by the fresh start and new attention (plus whatever theoretical
advantage any particular language provides), but unless it's suspect, re-writing
it for the sole reason of changing the language is unlikely to be a win.
In addition, a good programmer working in a 'bad' language that they are very
familiar with is going to write better code than that same programmer would
write in a 'good' language that they are not familiar with.
I git, the programmers are very familiar with C and Bash, but far less familiar
with either Perl or Python (although from what I see, far more familiar with
Perl than Python)
If it's something going into contrib, where the core developers are not needing
to maintain it, the language it's written in matters far less than if it's
something that's going to be in the core. If it's in the core, it needs to be in
a language that the core developers are comforatable with.
You may think that C and Bash are poor choices, but that is what the community
is familar with.
You are far from the first person to say that git should be re-written (or at
least large portions of it) in the language-of-the-day, and you won't be the
last (even, or especially if it does get re-written in Python ;-)
David Lang
--
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
