Question about C++ vs. Python/Ruby/JS plasmoids

[Aaron J. Seigo]

On Tuesday 26 August 2008, Paul B wrote:
> I've read before on several occassions that plasmoids should be written in
> Python(when the bindings are finished :P), Ruby, JS, etc. because that way
> they don't run in the plasma process, and a crash will not bring down the
> entire desktop.

not quite accurate; they do run in the pasma process but as they aren't 
running native code errors in them won't bring down the entire desktop. 
instead, these errors, or "crashes", are caught by the runtime/interpreter/vm 
and handled gracefully.

> Have you thought about switching over the core plasmoids to a scripting
> language?

in addition to the reasons Alex pointed outfor not doing this, there's also 
the issue of efficiency when it comes to some of these common, core applets.

however, i also agree with Alex that it would be great to get some non-C++ 
applets in svn.

truth is that it's not been as easy to write scripted plasmoids as it was to 
write C++ applets until rather recently, and that hasn't helped.

> Is there any language that could be used without adding
> additional dependencies to plasma (QtScript?),

ECMA Script (QScript) would be the one, yes.

> or if not, do you think it
> would be worthwhile to pick one language and make that a dependency?

they will be once the ScriptEngines make it into kdebase. even then, though, 
they will still be optional in the sense that, except for the ECMA Script 
ones, they are not necessarily guaranteed at runtime as the python, ruby, c#, 
etc support may not be installed on the system in question.

in the future, the probability of this in actuality will be lower, but still 
possible. so writing core plasmoids in anything other than C++ or ECMA Script 
is probably not a great idea. non-core plasmoids can be written in whatever 
people want AFAIC.

*that* said, there's something to be noted here with regards to efficiency. i'm 
not sure it makes sense having 3, 4 or however many languages required to run 
an interesting plasma system as that means running the interpreter/vm for each 
of those languages.

other than "because i prefer to write in python" i'm not overly sure what real 
world compelling benefits there are to other languages. i think it's great they 
are there, if only because people can and should work on whatever they want 
to. but for our own "official" set, i think it makes most sense to try and stay 
within the bounds of C++ and ECMA Script.

> I understand that for some tasks C++ may just be an easier and more
> efficient language for doing this, but to have ALL the core plasmoids use a
> system that, as has been said before, could bring down the entire desktop
> seems a bit reckless.

in that case, let's rewrite all KDE applications in something other than C++. 
*smirk* given that the desktop restarts itself if something crashes and that 
we should be working on the quality of these core plasmoids, i don't think 
it's an issue worth being concerned about.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20080826/ab60f786/attachment.sig