[Thunar-dev] next step in thunar development

[Benedikt Meurer]

Jeff Franks wrote:
>>Just to make sure there's no misunderstanding: While this sounds like we 
>>are limited to C as implementation language, its not the case. The core 
>>will (and has to be) written in C. For the upper layers, esp. plugins at 
>>a later time, I can imagine several programming languages. I think Java, 
>>C++ and Python are the ones of interest here.
> 
> Benny,
> 
> For XFC 4.3.2 I want to provide wrappers for the Xfce4 libraries and 
> this has had me wondering about libexo, your Xfce4 widget extension 
> library. Clearly Thunar will depend on this library but it isn't in the 
> Xfce4 SVN like Thunar. Does that mean that Xfce 4.4 will depend on an 
> external library or do you plan to move it to the SVN. Currently XFC has 
> these modules: libXFCcore, libXFCui and libXFCglade. If libexo were in 
> the SVN then I could include possibly one or two new modules: libXFCxfce 
> and/or libXFCexo.

I know, moving Terminal, libexo and the installer is on TODO. Maybe this 
weekend, depends.

> On another note (please everybody, lets not start a long pointless 
> discussion about this) I just wanted to say - I hope everyone thinks 
> carefully their choice of language. Their is no doubt C++ has the 
> beneift of raw speed and power over Java and Python (which are easier to 
> use but slower). Surely, its important to keep Xfce4 not only easy to 
> use but fast as well. I think minimizing the number of different 
> langauges used to program one application will make future maintenance 
> easier. Here are a couple of benchmark links you can check out:
> 
> http://www.flat222.org/mac/bench/
> http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html

Actually, if you look at the average Gtk+ project (using the C API) for 
example, stuff is usually horribly un-modularized and there's no overall 
organization (many times you see projects that share a vast amount of 
global variables all over the code or separate code by callbacks and 
other functions, not by the data they act on, etc.), that things will 
slow down very much after some time (adding code, changing code, ...), 
simply because people aren't able to overlook their project anymore and 
so they'll start to call random functions in the hope that the result 
will be the expected result, even if calling this function introduces 
performance problems (which is not obvious as the problems are hidden 
deep within another function, thats not linked to this function in a 
developer-visible way).

Now that's nothing new and nothing bad (atleast if I don't have to 
maintain such a project). Most people in the open source are hobbyists 
and in the end we're all human. My point is that choosing a "fast 
language" does not mean that the program will be fast.

The benefit of high-level languages is that they force people to think 
about their doings many times (C++ is not really one of these 
languages). For example, with Java, people will be forced to think about 
modularization, because you cannot simply access globals and use only 
static functions without running into serious trouble (as demonstrated 
above, you'll run into trouble with C as well, but with Java you'll 
notice problems way earlier, esp. since not a single Java book would 
suggest developing with global variables and static functions, while 
most C books do).

So, to conclude: Using ("not very fast") high-level languages can help 
inexperienced people to develop programs that'll run faster (atleast 
after some maintaince time) than a program they would have otherwise 
hacked together in a "fast language" like C or C++ (both can be very 
benefical and C++ is definitly a very good language with support for 
high-level constructs, but for the average open source hobbyist, it's 
just too easy to shoot yourself into the foot, just because he doesn't 
know the important bits of the compiler or the runtime environment).

> Regards,
> Jeff.

greets,
Benedikt