Using scripting languages for KDE4 main modules

[Stephen Leaf]

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 
meant for.
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 
basic functionality.

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

Stephen