language choice of alfs

Hui Zhou zhouhui at wam.umd.edu
Mon Dec 20 12:58:40 PST 2004


On Mon, Dec 20, 2004 at 08:49:08PM +0100, Joachim Beckers wrote:
>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, 

The existing profiles for lfs is not 'heavy' at all. The whole blfs 
profile may be heavier, but again the parsing part only happens at 
initialization, a few minutes compared to hours of building time 
really won't bother a lot of users. Once the profiles includes 
packages as many as those in debian depositories, it is indeed heavy, 
but at that point, a better solution is to split the profiles into a 
data base, otherwise, even a fastest engine will feel slow.

>copying files, building packages, 

nALFS spawns shell run these tasks. Unless all these tasks were 
recoded in alfs, language choices won't make measurable differences.

>logging 
>packages' output and details, aso. 

If the logging is just streaming out to a file, the overhead of these 
is immeasurable, unless the logfile has a complicated structure and/or 
alfs need do some formating before output. In most case, the IO 
shadow's every thing.

>I personally wouldn't trust a script 
>that's doning all that. As mentioned before: scripting languages just 
>weren't designed for such tasks.

On the contrary, scripting languages such as perl is especially designed 
for these tasks. They work like a charm to glue together tasks such as 
compiling and linking. 

>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. 

It's funny I think the opposite. The backend deals with a finite set 
of data and just runs applications on these data. Once the structure 
of these data is defined, there is nothing complicated. On the other 
hand, the front end deals with human, which is an infinite set. Of 
course if the designer willing to let the user to compromise, and 
offer just a shabby interface, it is easy. But once start to 
considering the user convienience or friendliness, it is a never 
ending business. The way I see it, the developement of GIMP is mostly 
on the UI part which is the exact place makes Photoshop so much 
better. It is not clear yet, but I assume the task of analysing the 
command output and produce a nice summary or progress to the user is 
in the frontend, which could be the most heavy part in alfs.

>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.

I don't see the obvious reasons ;-)

IMHO, if the functionality of frontend and backend is clearly divided, 
there will not be much need to share data structures, so either can be 
implemented independently, which could be a very nice thing. 

Regards,
-- 
Hui Zhou



More information about the alfs-discuss mailing list