Please note that my contributions to gnulib-tool so far have been nonexistent; weigh my statements accordingly...
On Sun, Jan 4, 2009 at 10:25 PM, Bruno Haible <[email protected]> wrote: > If gnulib-tool was to be rewritten in another programming language than > shell + sed, what would be the good choices? > > The foremost criteria IMO should be the maintainability, i.e. the ability for > us and for new contributors to gnulib to master this programming language. > To get an estimate of this, there are various sources of information. [...] > 2) We can also look at the level of familiarity of the current gnulib-tool > maintainers with these languages. Among us recent contributors to > gnulib-tool > (Eric, Jim, Ralf, Simon, and me) two of us have made public their skills: > <http://savannah.gnu.org/people/resume.php?user_id=1389> > <http://savannah.gnu.org/people/resume.php?user_id=1871> > making up for: > C - 2 x master/expert > Java - 2 x master/expert > C++ - 1 x master/expert, 1 x good knowledge > Python - 1 x base knowledge > perl - 1 x base knowledge (FWIW, I'm expert in C, C++ and Python, with good knowledge of Java and a base - and falling - knowledge of Perl). > So according this criteria, only C and Java remain possibilities. Python and > perl have to be excluded because too few of us are skilled in these > languages. Except for the possibility of attracting new contributors. A 4000 line shell script is no doubt a little intimidating to some potential contributors, for all that the existing code is well commented. > 3) Long-term maintainability requires some degree of standardization, so > that the amount of expected future changes in the language and its runtime > library is small. This speaks in favour of C, Java, C++, and against > Python and perl. I assume you are referring to backward-incompatible changes only. The actual amount of work involved with keeping up with Python language changes would be, I'm sure, minimal. Something like two hours per year, on average. > 4) For comparing simply the syntactic complexity of the languages (yes this > is only a small facet of maintainability, but nevertheless), one can take > the amount of code needed for writing a superficial parser. Such parsers > are implemented in gettext/gettext-tools/src/x-*.c, and x-perl.c is more > than twice as large as the other parsers. This indicates that also for a > human developer, perl syntax is harder to grok than the syntax of other > programming and scripting languages. > > In summary, C and Java come out as best candidates, whereas a choice of python > or perl would be very unwise. Certainly C has the advantage that diagrams of the bootstrap process will look a lot more fun. I'm not really very keen on the Java option; bootstrapping takes enough time already, I don't want to pay the startup times repeatedly (the best command-line Java program I've ever used has the feature that it forks and runs in the background as a server; the front-end is actually written in another language). James.
