Using scripting languages for KDE4 main modules
smileaf at smileaf.org
Sun Oct 1 19:40:32 BST 2006
On Sunday 01 October 2006 7:31 am, Guillaume Laurent wrote:
> On Sunday 01 October 2006 13:00, Alexander Neundorf wrote:
> > I don't think it would be possible to reach a consensus on this one:
> > python <-> ruby <-> java <-> c# ...
> We want a script language, so Java and C# are out of consideration, the
> added value compared to C++ just isn't worth it. So it's between Python and
> Ruby (at least we all agree that Perl is a no-go :-) ).
not everyone, I hate the python syntax. And as for ruby syntax?.. I've seen
scribbles that were more readable. Maybe it was just the examples on the
official page I dunno but it just churned my stomach.
I personally prefer Perl out of those 3 choices.
> My own preference would be toward Ruby, but I think the safe choice would
> be Python, because of its "there's only one way to do it" syntax.
If I had to pick between just python and ruby tho, I'd pick python because
it's a requirement for programs I already have installed.
I refuse to install ruby just for amarok for instance. Why? because another
dependency for only 1 application and for things that I really don't need
just doesn't sit too well.
so I personally find it quite annoying that so many plugins require it. but at
the same time it doesn't bother me because I can still use it for what it was
I'd be 100% Ok with a soft dependency on any language.
such as if the interpreter is found, it'll install that program/plug-in.
I would be against having it absolutely require one of those languages for
As it was said in 1 email:
"Banning scripting languages in this case will NOT somehow magically convert
features A, B and C into streamlined C++ code. What it will mean is that
those features will most likely NOT get written at all and no one will have
the option using those features if they can afford the extra RAM, disk etc
Allowing scripting languages isn't going to magically turn any C++ into
Python, Ruby or whatever. People are always free to step up and contribute
C++ code. Nothing changes there. Like any new dependency, developers will
need to weigh up the pros and cons and decide for their project if the cost
is worth the benefit, and how best to use it." -- Simon Edwards
I agree 100% and to add to it, Allowing non-C++ programs/plugins isn't going
to magically get features A, B, or C either. Will it make it more possible?
perhaps At the same time tho it is quite visible that scripted programs are
slower than your streamlined C++.
I refuse to install Superkaramba because when it was loaded my system actually
was completely bogged down. It was a slow system, which shows this more
I am not against adding non-C++ languages to KDE's ability.. I am against
having core functionality use them. A Basic KDE system IMO should include no
non-c++ program/plugin loaded. If the user wants to extend their desktop and
load/install them more power to them.
More information about the kde-core-devel