Using scripting languages for KDE4 main modules

[Leo Savernik]

Am Sonntag, 8. Oktober 2006 20:21 schrieb Aaron J. Seigo:
> > > i don't think it's too much to ask for kjs or qsa. they are both
> > > lightweight and at least kjs is already in use on your desktop if you
> > > use konqi.
> >
> > Is KJS the same code that renders javascript inside pages? If yes, its
>
> yes
>
> > used, but only when web browsing certain pages. Sure, KDE user should
> > always have a Konqueror window open and they should use it as their
> > browser, so you have a point here. ;-)
>
> =) additionally, if no one has issues with it as part of the default web
> browser, why the issues with it elsewhere?

The fundamental problem with scripting languages, be it purely interpreted 
like kjs or jitted like perl, which people tend to forget is this:

The real memory hog is the representation of the abstract syntax tree and all 
accompanying management objects. For *every* statement, *every* variable, 
*every* call, and *every* reference you need a dedicated object in memory 
*which cannot be shared* (to the contrary of the native script interpreter's 
machine code which, as an .so, *is* shared).

Those cannot be shared because they represent *different* scripts which are 
going to be executed. Even jitted script-languages provide dynamic 
introspection and evaluation features which still forces the engine to keep 
elaborate AST-information around.

Therefore, really basic features like a *clock*-applet must not even remotely 
be considered for contamination by scripts. (So, maybe there'll be a 
Dashboard-MacOSX-clock in javascript, but the basic desktop must contain a 
clock-clock in C++ which fulfills nothing but the tasks of a clock in a 
memory-efficient and performant way.)

mfg
	Leo