On Wednesday, May 7, I attended a session at JavaOne where a panel of experts on dynamic languages fielded questions from the audience. The experts included: Tim Bray, Charlie Nutter (JRuby), Tor Norbie (NetBeans/dynamic languages), Ted Leung (Python/dynamic languages), Greg Murray (JMaki), Bob Bruin (Java FX), Thomas Enebo (JRuby), and Frank Wierzbicki (Jython)

Here is a transcript of some of the more interesting questions and answers. Some questions were simply re-phrasings of earier questions, and some offered much debate. The discussions have been left off for brevity. 

Question: What is JMaki? 

Answer: JMaki allows you to express Ajax functionality without regard to language or runtime (see jmaki.com). 

Question: Groovy is very Java-like, why do we need it?

Answer: Groovy goes way beyond Java in several areas, most of all in terms of the learning curve. It also includes a web framework that makes it easy and quick to build web applications.

Question: Why not use one of these languages for Java FX instead of Java FX Script? Was it really necessary to create another dynamic language?

Answer: It's true that Groovy with its Swing support can do a lot of what Java FX Script does. However, JavaFX was designed for content authors, not really developers. Also, Java FX is meant to build rich user interfaces, and aimed at addressing Flash in this space.

Question: Why do we have and need so many dynamic languages in general?

Answer: No one language is ever going to solve everyone's (and every application's) needs. Diversity of languages on the JVM is a good thing since there's never going to be a single language for all needs. 

Question: Why port dynamic language runtimes to the JVM? Why not just leave them native?

Answer: In many cases, dynamic languages can run faster on the JVM than native because the JIT compiler does run-time optimizations as opposed to static compile-time optimizations for the native run-times. Also, it allows one implementation to run wherever the JVM runs, which is pretty much everywhere.

Question: When will Ruby on Rails performance improve?

Answer: It will happen! Adding functionality, and addressing compatibility, have been priority issues. JRuby applications will run better on JRuby now and going forward. Some of the performance issues are with JRuby, some are with the Rails framework. Both sides are working together to solve these issues.

Question: Why have there been no Ruby, Python, PHP (and so on) implementations for .Net's CLR?

Answer: Platform independence and portability. The write-once-run-anywhere mantra of the JVM makes it appealing to dynamic language developers. Also, since Java grew out of a Smalltalk VM, it's built on a dynamic language-enabled VM. This makes it more suitable for dynamic languages than something like .Net.