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.
