Re: choice of implementation language

[Jim Meyering]

"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.
>
> 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.

IMHO, a rewrite makes sense only if it's in a scripting language.
Perl has been de-facto standard/portable.  The lack of a committee
sanctioned standard is not a problem (may even be a feature) in its case.

If we stick to languages in which we are already expert, our skills will
tend to stagnate.  I think it's worth considering Ruby, and would be
willing to use it in this case, in spite of the fact that I have far less
experience with it than with Perl.  Think of it as a learning opportunity.

Remember: this is a developer tool, after all, and not something
with the portability constraints of a configure-time script.

And also, consider that we're not going to throw away the shell-based
tool -- at least not right away -- so having parallel implementations
lessens the portability burden on the new one.

So I conclude that the choices are

  Perl
  Python
  Ruby

If using Perl, we could easily restrict ourselves to
features of 5.8 or even older.  With Python and especially Ruby,
I'd advocate requiring much more recent versions, due to their relative
immaturity.