Computational Theology Gilad Bracha's Sun Weblog

 

We’re looking to improve support for dynamically typed languages on the Java platform.

  Tangent : that’s dynamically typed languages - not the increasingly common horrible misnomer dynamic languages (as opposed to static languages, where nothing moves, like hieroglyphics, perhaps?).

A lot of hype has been generated over the .Net VM’s support for multiple programming languages.

Another tangent: I always refer to the .Net VM and not the the CLR. It’s a VM, such things have always been called VMs, and the only reason I can think of for giving it a different name is to confuse people. Confusing people might be useful if you wanted to convince them that you’ve invented something when you actually copied it from somebody else.

More generally, jargon has been used throughout the ages to intimidate and exclude. This is a tradition in every profession: don’t say parameterized type when you can say parametric polymorphism .  

Introducing non-standard terminology is popular in industry, as it prevents people from easily comparing your product to others, so that they aren’t tempted to defect. It’s a common trick used by many large companies throughout the history of computing. For extra credit - what’s a long, complicated term for a B-tree?

The fact is, the .Net VM provides support for all manner of statically-typed, single-inheritance imperative object-oriented languages. It could potentially host C#, or Java, or Oberon or Ada or Modula-3 just fine. In other words, you can program in whatever you want, as long as it is basically C#.

Despite the hype, languages with fundamentally different models won’t work all that well. For example, if you don’t have static type information, you cannot use the VM’s highly tuned dynamic dispatch for method calls, and end up doing your own emulation in software. This is tiresome for the implementor, and more importantly, really slow.

The JVM is not really that different. In fact, a study done by some folks at Aarhus University, part of the culture that invented object-orientation, found that there was no significant difference in difficulty between porting Beta to the JVM or the .Net VM.

So what can we really do to make dynamically typed languages easy to port, and port so they run well, to the JVM?

Last winter we had a meeting with various people who work on such languages - things like Groovy, Perl, Python/Jython.  Our conclusion was that the most practicable thing was to support dynamically typed method invocation at the byte code level.

The new byte code, invokedynamic , is coming to a JSR near  you very soon. I’m forming an expert group which I will chair (because of my deep fondness for standards, committees, meetings and process). This group will get to argue over various fine details of how this instruction should work.

Basically, it will be a lot like invokevirtual (if you don’t know what that is, either open a JVM spec and find out, or stop reading). The big difference is that the verifier won’t insist that the type of the target of the method invocation (the receiver, in Smalltalk speak) be known to support the method being invoked, or that the types of the arguments be known to match the signature of that method. Instead, these checks will be done dynamically.

There will probably be a mechanism for trapping failures (a bit like messageNotUnderstood in Smalltalk).

Does this do everything everyone wants? No, but that is not the point. It isn’t really feasible to accommodate the exact needs of a wide variety of disparate languages. Instead, one should provide a good general purpose primitive, that all these languages can build on.

Some might like the new byte code to support multiple inheritance - but each language has its own multiple inheritance rules, and supporting all of them is hopeless. In most cases, the lookup process for multiple inheritance can be benefit from this primitive.

Dynamic languages with a clean single inheritance semantics like E will be able to use this primitive directly for most calls.

Another problem is calling methods written in Java from a dynamically typed language. Static overloading makes this tedious. Languages may have varying mechanisms for dealing with this, often reminiscent of multiple dispatch. This is way too complicated to put into the VM, but the trap mechanism mentioned above should help implementors deal with that problem relatively efficiently.

All of this should eventually make it the use of dynamically typed languages on the Java platform easy, efficient and common place. That’s a good thing. I’ve long been a fan of such languages (well, not the popular ones; rather, languages like APL, Scheme, Smalltalk and Self; face it, I’m a snob and proud of it).

Why does this matter: I’m convinced these languages have a growing role to play in the practice of computing in the coming years. The extra flexibility of dynamic typing will become more and more important as software evolves.

This is not to say that static type checking is to be avoided. As I indicated in my prior posting about pluggable types, the static-vs-dynamic typechecking wars are pointless; one can eat one’s cake and have (most of it) too.   Invokedynamic is a modest, pragmatic yet very important step that helps the JVM become a hospitable environment for such cake-eating and having.