Just putting this discussion in the kdegames BoF context, we were mainly 
contemplating the possible usage of scripting languages where they make 
sense, for configuration, some AI routines, level design and 
description, and themes. I believe no one was actually advocating the 
possibility of writing full game engines in scripting at this time, even 
with stable bindings. The consensus was to do more or less what is 
already an established practice in the gaming industry: write your game 
engine in C++, and use scripting for level description, AI and others.
KJSEmbed is a good candidate, of course. Except that I have to agree 
with a previous poster: I do not know of any game scripted in 
JavaScript, commercial or no. There are however thousands of Flash-based 
games and apps, so if you write a developer-friendly C++ game engine 
with a JS scripting interface this could work nicely. There are bad 
games written in Flash out there, but there are some masterpieces as 
well, better than anything we have on kdegames currently, for example.

Taking the case of games in particular, if you examine the scripting 
languages used currently for commercial game development you will find 
that the  most popular one is Lua, followed distantly by Python. Lua is 
used extensively in games like FarCry (scripting all game events and 
AI/game logic, both for single and multiplayer game, and for realtime 
game editing), World of Warcraft (UI customization), Grim Fandango 
(scripting), Psychonauts (whole game scripting and simulation), Baldur's 
Gate, etc.

Reasons for using a scripting language like Lua in games specifically 
are well known, as it is ideally fitted for data description and 
implementation of finite state machines for AI. The discussion about 
performance is not really applicable. Scripting is of course a resource 
that has been proved valid in gaming, even on applications where every 
performance optimization counts, as in the case of a FPS game like 
FarCry. Developers know that 99% of the time is spent in the C++ game 
engine anyway, the memory overhead of the Lua interpreter and the script 
execution time is insignificant given the advantages offered by the 
ability to control the whole game simulation via scripting. Using 
scripting in this way is an established practice in the games industry.

Notice that I am not advocating the usage of Lua specifically in 
kdegames, as it has some technical disadvantages as well in the specific 
context of a project like KDE. And basically because there is not (yet) 
a need for it, so I do not want a hammer if there are no nails to hit. 
But for longer term planning we discussed in the BoF the possibility of 
converting 20 games to maybe 3 or 4 game engines, and driving the 
simulation via scripting. It will not happen now for KDE4, but it may 
happen in the future, and open the door for more user contribution.

For educational applications Python or Ruby are probably better suited, 
I imagine.  But for the reasons explained above (and others) I believe 
forcing one scripting language standard of course is not going to work. 
No one has even talked about Lua in the thread for example, and it is 
practically the standard scripting tool used in the gaming industry.

We should however make it clear that scripting should be used where it 
makes sense, as in the game engine scenario above, Krita plugins, etc. 
Writing a whole game in PyGame just because the developer does not know 
C++ does not qualify, imo. Scripting should be a choice that comes 
naturally because it is better for the application, not a way of simply 
lowering the barrier for code contribution artificially, otherwise we 
will probably simply end up with bad scripting code.

Regards,
Mauricio Piacentini