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. 1) We can look at the number of developers who master one language or the other. This matters because we cannot force or expect gnulib contributors to learn a new programming language, just for gnulib-tool. I compared C, C++, Java, shell-script, Python, Perl in ohloh: <http://www.ohloh.net/languages/compare?commit=Update&l0=c&l1=java&l2=perl&l3=python&l4=shell&l5=cpp&l6=-1&measure=contributors&percent=> The result is the following ordered list: 1. C 2. Java 3. C++ 4. Python 5. perl The comparison by number of projects rather than by number of developers <http://www.ohloh.net/languages/compare?commit=Update&l0=c&l1=java&l2=perl&l3=python&l4=shell&l5=cpp&l6=-1&measure=projects&percent=> yields the same result. 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 Also, I know that a few years ago Paul did not know C++ and was not inclined to learn it. 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. 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. 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. Bruno