Re: choice of implementation language

[James Youngman]

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 <address@hidden> 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.