nALFS programming details

Kevin P. Fleming kpfleming at
Mon Aug 9 16:27:26 PDT 2004

Matthew Burgess wrote:

> I was going to ask the same think myself, but didn't want to start a
> language-war :)  If C++ is chosen, there is of course libxml++ - a C++
> wrapper of libxml2.  Whilst not a 'real' C++ programmer by any means,
> I'd love to be able to use this as an excuse to do some real work in it
> for once.  Alternatively there are the more'modern' languages like
> python or ruby. <fx: Matt dons his asbestos suit /> :)

No need for any asbestos (cough, cough) suits here. I don't think the 
choice of language should be driven by what we know, it should be driven 
by the requirements. Granted, we don't really want to end up choosing 
something that none of us have any experience with, unless it's such a 
perfect tool for the job that we can't avoid it :-) I would rather see 
the requirements phase that we are in continue to develop more and more 
complete documentation, along with one or two people putting together 
prototypes of various pieces of the puzzle to flesh them out and test 
any assumptions we have made.

For example, I have a friend who has been playing around building an 
email client (don't ask why, I don't really know <G>). He spent about a 
week learning Python and PyGTK (among other tools), and in another 
week's time had a nice looking and functional (albeit slow) user 
interface built that demonstrated what he wanted it to look like. 
Someone who wants to build a GUI front end for nALFS2 could do the same 
thing, and then later choose to implement it in a compiled language instead.

More information about the alfs-discuss mailing list