Re: choice of implementation language

[Mike Frysinger]

On Sunday 04 January 2009 17:25:40 Bruno Haible 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'm not sure this sampling makes sense.  for example, the common languages 
used in web applications, or libraries, or GUI applications should have little 
to no bearing ...

> In summary, C and Java come out as best candidates, whereas a choice of
> python or perl would be very unwise.

i would state that java is not even close to a usable state for usage across 
open source platforms.  i personally run gnulib-tool on non x86/x86_64 
systems, and java would be a big hindrance here (on some systems, it's 
practical if not literally impossible) ... it's a pain even on x86/x86_64 
systems.

considering the amount of string parsing that goes on, i'd think that would 
rule out any compiled language (like C or C++).  you spend your time fighting 
stupid things like memory and string parsing instead of getting real work 
done.  sure gnulib-tool will be slower in shell scripts, but it's a lot easier 
to prototype/hack on than any compile language will ever be.  plus, gnulib-
tool isnt time critical at all, so performance differences here are 
irrelevant.

but i'm not a maintainer so what do i know ;)
-mike

signature.asc
Description: This is a digitally signed message part.