[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
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.
Re: choice of implementation language, Micah Cowan, 2009/01/06