An extension to the topic of built-in "transcompilation" I started, I expect that if community consensus leans in favor of adding such capabilities down the line that the topic of using other scripting languages in general would inevitably be raised again. This thread, therefore, is anticipation of such and I highly recommend taking part in the transcompilation discussion first before this one as the two are related but this would likely need to build off that first.

In the future, do we want to expand the Sphere engine's capabilities to properly allow other scripting languages to be used within the engine?

Besides adding the full-on scripting environment(s) in question, barriers to this proposition would include implementing Sphere's specific API (or a reasonable facsimile thereof) in said language(s) and the loading of Sphere formats (which is probably the easier of the two).

Python specifically seems to have a gaping hole with PyGame not being updated since 2009 and ika not since 2010 (its last ppa update was for Ubuntu Maverick Meerkat; can an Ubuntu user confirm whether its corona and audiere work for Sphere on Ubuntu?), but both communities are still rather strong which says to me Python is a popular scripting language for game development. I haven't done the research on Ruby or Lua, but RPGMaker is still among the most popular commercial game development systems and still uses Ruby, and Lua has been used even by "AAA studios" for "AAA games" (including Street Fighter IV).

I'm not explicitly saying we should recreate ika, RPGMaker, Love, or another existing engine with separately updated scripting languages; they have their own APIs that are likely not one-to-one with Sphere's and their formats are also not directly binary compatible with Sphere's (though the latter can probably be resolved with simple converters).

There's probably other factors in play with such a decision as well. This is the topic for such discussion.

I for one can say that no version of Corona works with an even close to up to date version of libpng (as attempted on Fedora 14, 17, 19, and ArchLinux). Audiere still seems to compile and work pretty well.

When I was building my plugin interface, I thought about working to allow other engines to be used. A frontend and backend, like the GCC. In the end I abandoned the idea because I did not have the energy or know how to make it happen. But the idea of having an engine and plugin spec that would allow any scripting language to use any plugin was pretty appealing.

I would be open to working with someone to make this happen with TurboSphere--to make the plugin interface language independent, and writing another engine binary that uses a different scripting language. It probably wouldn't be the faster or easier way to make PySphere or LUASphere or PHPSphere or SphereScriptSphere, but if we wanted to make more than one then I think it would at least be worth considering.

I'm up to making a python port of sphere in .NET: http://ironpython.net/

I'm up to making a python port of sphere in .NET: http://ironpython.net/

I don't follow. I'm talking about the ability to use a different scripting language than JavaScript (eg, Python) within Sphere, what are you talking about?

I don't follow. I'm talking about the ability to use a different scripting language than JavaScript (eg, Python) within Sphere, what are you talking about?

That.

No no, I think he meant doing that in stock Sphere, hence use of the term "transcompilation".

The "transcompilation" discussion was primarily for X-to-JavaScript conversion (preprocessed or runtime) in stock Sphere, but as I said I wouldn't be surprised if that leads to an increased potential in the direct use of other languages like Python, either built-in or via plugins like how TurboSphere does.

IronPython is just like Jurassic you use it to execute code in another language while being able to introduce an interface with the host language - C#. In fact there is an IronJS but it's not very mature in development.

Funny I find this topic now, as early in minisphere's life I contemplated implementing the Sphere API in Lua.  Ultimately I chose not to, probably right around the time I decided it was best to shoot for a compatible engine first before worrying about extra bells and whistles.

That said, under the hood there isn't a whole lot stopping me from implementing such a thing now--most of the Duktape bindings are simply stubs which call out to other functions to do their work (this is how actual Sphere is set up too, incidentally).  This ensures that any component exposed to script can also be used just as easily internally, and keeps the argument sanity checks at the JS/native boundary where they won't bottleneck internal calls.

So long story short: Pluggable scripting languages wouldn't be too difficult--assuming I had the interest to do it. . Really, I love JS too much to consider using any other language at this point...

I thought about doing something similar in TS. I could generalize the plugin API so that it was no longer tied to my JS engine, and then I could load both plugins and any language with bindings.

But...I guess I don't really see the point of that. It's a cool idea, but two big problems are that it's really complex, and it would generally make it hard to really take advantage of any particular language. I'm much happier with an engine that is well thought out in a single language.

There's also the issue of fragmentation.  Unlike .NET where all languages compile down to the same bytecode format (which has its own problems, of course--identifier casing and differences in reserved keywords, for example), Sphere scripts are provided in source code form, so a library written in JS wouldn't be usable in an engine using Lua, say.  I think it's ultimately better for all involved if we just standardize here and say Sphere games are written in JS, period, instead of trying to please everybody.