Monday, May 19, 2008

CommunityOne 2008 - The Road to Babel: Bringing the JVM Language Implementers Together

Charles Nutter, SunMicrosystems

Language survey: 200+ lands
Nolanf is inpossible fix are most diff, dynamic are hard to optimise. No Lang is too weird

Functional Languages:
clojure:
Lisp dialect but easier to read and write.
- Released every 3-6 weeks. Getting exposure now.

Kawa: Implementation of scheme. One of oldest compilers.
- Currently v1.9.1. Multiple projects using it. Open secret.

Ocaml-java: Very expressive. Functional, imperative and OO styles, need to set up external files to bind to java calsses
- 1.0 out in beta now. 2.x branch comping to focus on speed.

Scala: OO, ( classes, traits and mixins)
Statically typed. Nice looking DSLs. Fully interoperable with Java
- 2.7.0 is final. 5000 downloads / month. The Lift web framework is gaining traction.

Groovy: many features from Python and Ruby. Always JVM Lang. Has closures, mutable classes with a very java-like syntax. Has many libraries built in.
- 1.5.6 is current. 1.6 is out in beta. (Perf improvements - 500> in some cases and tidied bytecode)

JRuby: Ruby on the JVM. Rails and most other frameworks run. It's a Ruby for the java world and integrates well with java.
- 1.1 out a month ago. (Perf improvements.) The most compatible with Ruby 1.8. Future: more speed and comparability (groovy-level comparability). Share some low level advances with Groovy etc.

Jython: well structured, (honest). Wide range of libraries and applications. Can call into java.
- 2.2 is in prod. Behind phython. Large userbase. Trunk is 2.3 compatibility and aiming at 2.5. New compiler and parade being worked on. Already sharing a posix layer a. Jruby.

Rhino: dynamically typed and functional-like. Very flexible. Pervasive on the client, more on server coming up.
- 1.6r2 in Java 6. Interpreted by default but can be compiled. 1.7 will be java script 1.7 compatible. Ecmascript 2 is being tracked.

Case study:
JRuby. Dynamic typing is hard. Ruby has its own type system, continuations, etc. It also has Real world dependencies on c extensions.

But pushing boundaries on the jvm. This brings Java new blood, new ideas. Thus the JVM may be a better ruby runtime.

Complex: JRuvy does mixed mode- interpretataion, then compile later. Profiling is to be added. It has a custom string, array ( list), hash(map), regexp. It generates code to avoid reflection overhead. Multiple can run on a single JVM. Therefore you can have lots of Ruby apps on one JVM.

What would make it easier?:
- Lightweight code generation and loading.
- A faster-than-reflection method object.
- A tool chain for parsing interpretation and compiling.
- A more flexible JVM type system.

Collaboration: much is common across these languages. There are many similar problems. All are growing the platform. Consequently the platform is being pushed forward and extended.

Jvmlanguages group ( google group )

Jvm language runtime ( inspired by MSFT) should be general. We can gather the best libraries together and provide a fast track for implementation.

Possible new bits:
- Toolchain for parsing, interpretation and compiling: Antlr++?
- Language agnostic type inference: repurpose Scala or Haskell?
- Metaobject protocol? Flexible class definition. Learn from Groovy's MOP.
- Reflection-free method handles.
- Specialised types: c.f Ola's YAML parser
- The NLT is out there already

DaVinci VM: This is an open jdk based multi language vm.
It has anonymous classloading, lightweight method handles, optimised dynamic invocation, continuations, tail call optimisations, and tuples.

Your future: you are the community. You are not as dumb ss you think. You'll be a better person as a result. OSS is good for your career. You don't need to know about how to write a compiler. Be a polyglot - consider many languages for each problem.

Get involved: easy (core type systems) run rests and fix bugs. Interpreters are harder but basically the tree walker or walks the bytecode. Compilers are difficult but fun. Tree walk (easy) generate bytecode (hard and obscure)

What about IDE support?: generally driven by usage. Netbeans support is generic.

No comments: