Lots of buzz on adding scripting interfaces to applications on Planet GNOME recently, cool. Looks like Alexander Larsson hacked together a wrapper around SpiderMonkey (the Mozilla Engine) to get JavaScript integrated. Related to the jscore-python thing I blogged about before.
Not sure this is the best way to tackle this cool new opportunity though. JavaScript can be pretty hard to “get” for people not used to it, but more familiar with classical languages (wrt object oriented paradigms). I guess lots of current code contributors are not very familiar with JavaScript, but do have an in-depth knowledge of some other scripting language though (not listing any here, you certainly can name some).
So, wouldn’t it be nice if the GScript interface would be abstract for the application developer, who should just create a script context, put some objects in it, and launch a script, after which the GScript runtime figures out which interpreter to use for this script, so scripting languages become plugable?
Reminds me a little of my old OPluginManager work 
For once maybe something *shouldn’t* be pluggable and force standardization. Wouldn’t it be nice if you only had to know 1 language to understand any gscript?
I am *totally* for pluggable scripting languages. Python, JavaScript, lua, throw in some LISP… hell, maybe even a Mono backend. Pure awesome.
It would of course be nice if there were a few you could expect all Gnome installs to support, so there is need to standardize a bit; but I don’t think there is need to artificially limit application developers in that respect.
The barrier of entry to JS is low, with lots of tutorials abounding. The effort required to maintain all the packages in all the languages is monumental.
I’d rather have only one language, even if it’s Ruby (which I never looked at). Learning a scripting language isn’t rocket science, and I believe that “learnability” would far more benefit from a centralized pool of information.
JavaScript has been around for some time. I suppose that it’s recent success is much because of the work gone into all those JS Libraries (jquery, prototype.js).
I suppose that we will have to provide something similar, a library matching GNOME/UI needs and enabling RAD (like jquery,.. do).
OR, perhaps, you could use a standardized bytecode “language” with support for multiple comiplers/languages of which a whole bunch are scripting/dynamic languages.
Ok. Can anyone say “MONO” (!!!)
in response to fabian:
do you think that a language is good/well designed if it isn’t popular until libraries exist that completely changes how you use it, almost to the point of changing the syntax?
in response to marcus:
I did not want to use popularity to judge about the design of a language. Personally I quite like JavaScript.
I just thought that there should libraries to ease the scripting of GUI components. This might help, to increase the language’s popularity within GNOME.
My thumb rule: Less lines result in fancy things: More popular!
Yeah, cannot disagree with that. As a scripting language I think JavaScript is nice, although I would prefer python. However, I do not want JavaScript to be the language-of-the-future, I do not want to write large applications in it or have it as the single choice. That is however another discussion and perhaps my I’m-sick-of-writing-apps-in-loosely-typed-languages-feeling spread into the wrong area here.
We’ve come to accept JavaScript as the language in web browsers, because it is somewhat embraced by W3C, but from my point of view, I see no reason why GNOME should care about this instead of choosing a superior technology, which has a lot of developers in the Windows world — which from what I can understand is the world we want to get/take our users from, so why not use something familiar to them.
Sorry, that was one long sentence.
I’d say, the question about what language and what library (wrapper about what we want to expose) to use, depends a bit on who we want to empower. And what we want or expect them to do.
I suppose we do _not_ want to integrate scripting, to get users to write complex applications. Then they can already use python/C# or some language mono supports. (But maybe they will write complex apps, who knows …)
So in my eyes it only makes sense to use some untyped language like JavaScript or lua, because python and c#(as an synonym..) can already be used. They are not really embed but got many bindings.
Oh and: If we want the users to really use scripting, we will have to offer tools (places here and there to code, validate, console, quick manual, easy way to integrate into apps[plugin..], …) as Benjamin Otte already said.
You are welcome, concerning long sentences.