language choice of alfs
jbeckers at linuxfromscratch.org
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.
More information about the alfs-discuss