[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: choice of implementation language

From: Mike Frysinger
Subject: Re: choice of implementation language
Date: Sun, 4 Jan 2009 19:01:51 -0500
User-agent: KMail/1.10.3 (Linux/2.6.28; KDE/4.1.3; x86_64; ; )

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 

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 

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]