language choice of alfs

Joachim Beckers jbeckers at
Mon Dec 20 11:49:08 PST 2004

James Robertson wrote:
> Hui Zhou wrote:
>> I know there is a decision earlier that the new alfs tool will be 
>> coded in C.
<snip -- merry christmas everyone :-)>
>> IMHO, C is the worst choice for the job. ATM, I recommend python.
<snip -- and a happy new year too :-)>
>> I understand that developers and the skills of developers is not a 
>> choice here, so if it will be C, so be it. But I think the arguments 
>> given before are quite moo-moo.
> Actually that is one of the reasons we are writing an SRS in the first 
> place.  If we write it correctly, you should be able to create your own 
> version of alfs in python if you wish.  One thing I personally would 
> love to see is a GUI client for X (e.g. GNOME or KDE - I use GNOME).  I 
> have seen lots of RH tools written in python to be run in X that are 
> very full featured.

Good point, I think most of us have forgotten about the frontend/backend 
split. We actually have to make two choices: obne for the backend and 
one for the frontend.

IMO, the backend should be written in some compilable language, like C 
or so. That's important because it will have to work under heavy loads 
when parsing profiles, copying files, building packages, logging 
packages' output and details, aso. I personally wouldn't trust a script 
that's doning all that. As mentioned before: scripting languages just 
weren't designed for such tasks.

For the frontend, I don't care which language we use. Developing a 
frontend should be quite easy once we have docs describing how to 
interface with the backend. PyGTK, GTKPerl, Tcl/Tk come to my mind, but 
  C/C++/C#/Java/VB are possible too (although I have some thoughts about 
VB not being a real programming language). However, for the *official* 
frontend, I think we should go for the backends's language, for obvious 
reasons of maintainability.

Just my two cents.

Joachim Beckers

More information about the alfs-discuss mailing list