Why choose a language when you can be a Polyglot

Flamewars between language fanatics often gets in the way of "getting things done". I pick up languages fairly quickly and appreciate their benefits and short comings. After a fair bit of survey it seems like no language will instantly have familiarity and features concurrently, not unless it is also attached to a time machine and a brain washer. So why not call a truce and support them all (or most) - on a half-decent industry standard VM (no matter how much you dislike oracle).

Dynamic languages are a lot of fun to develop with, you can create prototypes quickly and have a tight feedback loop of your application taking shape. Sometimes the heuristics built into an application are not the right ones (u,v in vector interpretation are swapped, some format loader does not quite do what you expect). The expert/inquisitive user should be able to fix these vagaries at runtime and make the application behave. Any self-respecting application should include such dynamic scriptablity (Qgis does via CPython/SIP, Geoscript is nascent).

The REPL based languages that we are aiming to support via JSR 223 include:

1. Jython - with standard JSR 223.
2. JavaScript - with Mozilla Rhino, browser JNI bindings can be lobbed in as needed.
3. JRuby - again we get JSR 223 for free.
4. Groovy - the standard interface is not enough for delving in the depths of Groovy, but it does the job.
5. R - I hacked together a placeholder based on the JNI based rJava project, there are standard implementations but they don't play along nicely with our integration framework yet.
6. Perl - Another day another hack for the Inline::Java JNI based calls to the Perl interpreter.
7. Matlab - I had a chance to delve deep into the innards of Matlab and discovered a native and jvm based beast. There are several hacks to talk to Matlab from Java including running your Java code on the same VM Matlab is running (it even includes the felix runtime and scr). For now I am using matlabcontrol with some JSR-223 linkage.

The current integration tests with patchwork hooks to convert SUN Spi to OSGi Services looks something like below.


INFO: Testing Script Engine: jython
Jun 19, 2011 12:53:36 PM org.trikend.script.test.ScriptTest testConsole
INFO: Testing Script Engine: javascript
Jun 19, 2011 12:53:36 PM org.trikend.script.test.ScriptTest testConsole
INFO: Testing Script Engine: jruby
Jun 19, 2011 12:53:37 PM org.trikend.script.test.ScriptTest testConsole
INFO: Testing Script Engine: groovy
Jun 19, 2011 12:53:37 PM org.trikend.script.test.ScriptTest testConsole
INFO: Testing Script Engine: R
Jun 19, 2011 12:53:38 PM org.trikend.script.test.ScriptTest testConsole
INFO: Testing Script Engine: perl
Jun 19, 2011 12:53:38 PM org.trikend.script.test.ScriptTest testConsole
INFO: Testing Script Engine: matlab

A JSR-223 bridge may not do it justice and we may have to write our entire high-reliability portion of the system in Erjang, but that will not stop me from adding an Eshell to the integration test next. The java scripting project feels dead for a year, possibly due to Oracle turmoil, if there is any news on this front and Github forks alive and kicking I would really like to know. Other syntaxes and languages with fun features to evaluate would be: Scala + Akka, Clojure and Gosu.