I've previously written about scripting languages in Java and some of the interop issues with them. My basic thoughts haven't changed, though I also haven't been playing with any of these lately. But I have some additional thoughts.
My DEmentor, John Duimovich (he's an IBM Distinguished Engineer), found me on Google Talk last night, and we ended up chatting about all kinds of stuff, and one topic was scripting language / Java interop. John threw out all the usual pro's that come with this sort of interop nirvana:
- You can write your (non-time-critical) business logic in a scripting language, which will be smaller and more readable than in Java, but more importantly, you can write it quicker.
- Your scripting language can make use of all the great Java class libraries available.
- You can probably make use of at least some class/function libraries in your scripting language from Java.
Sounds wonderful.
I think most people, when they hear interop stories, get afraid of performance. Ignore that one for now; consider that you could at least prototype your Java code in a scripting language, then convert to Java later. Interop would still be a huge benefit.
But performance isn't the issue. There are bigger issues. Let me recap, quickly. Read my previous blog post for more details.
- debug
- code completion on the Java you are 'writing' in your scripting language (I can't live without Java code completion)
- impedence mismatches between languages; especially typed Java arrays
My experience is that the complete story isn't really all that easy with these interop stories. Which is probably the best reason you would want to do this anyway. That takes care of the first pro.
For the second and third pro, I'll just ask: what libraries are you wanting to use in the 'other' language (be it Java or scripting language)? Is there really that much of a difference, these days, between the functionality of, say, Java, PHP, and Ruby? Functionality from 10K feet, because you obviously use Rails when using standard Ruby, and are using Servlets in Java (or worse); think holistically here. The answer is ... not really.
Is all hope lost? For language interop ... yes.
Does that mean implementations of scripting languages on Java is pointless? No.
IronPython performance is on par with python-c. So there's no reason why implementing a scripting language in Java isn't a reasonable option, though you probably want to factor in things like a need for invokedynamic and making Java a better C (more on that last one in a future blog post).
The question is, do you really need user-level language interop, or do you just need your scripting language and it's typical libraries? I say the typical libraries, because at some point you are certainly dealing with Java objects in your interpreter / runtime, but they don't necessarily need to be visible to the end user; the programmer in this case. And you could certainly invent a mechanism to allow scripting language functions / classes to be implemented in Java for those non-mortals amongst us that implement core libraries. Back in the early VisualAge for Java days, the Java natives were implemented in Smalltalk (boy, was that sweet!). Who used it? Not many people (well, we didn't advertise it), but not many people would have needed it anyway. Not many people write the core libraries.
Taking the burden off of the scripting language implementor to add an 'interop facility' is also a huge benefit. At least, an interop facility that you have to make available as public API.
End users (programmers) win, to some extent, because they don't have two languages/class libraries to deal with. They lose the theoretical interop benefits, but they never really had them anyway.
In the end, what's the real benefit to doing this? That we get to implement our scripting languages and their extensions in Java. And not C. Or worse. With the recent GPL-ization of Java, I'm hoping that we're going to see Java available much more widely than it had been before. Time to take advantage of this situation.
I've made all sorts of crazy assumptions here; please attempt to prove me wrong.
Photo 'Keep 'em separated' with a nice CC license, by Mark and Allegra Jaroski-Biava. Found using the Flickr's Create Commons Search.
Update: So one assumption I got wrong was that John was arguing for the level of Java interop that I'm suggesting is pointless. He wasn't. He's on the same page as me (well, closer than I thought). The problem is the term interop was used, and it clearly means different things to different people.
Useful interop are things like JNI, the Zend API, etc. Useful because I can interoperate with C, that can do anything it wants to on a machine. Useful, but difficult to use. Who wants to program in C? Especially with these rather arcane 'extension' libraries. That's not just C, that's complicated C.
When I hear interop, I hear the "end user programmers can talk to Java directly from language-X". When John hears it, he's thinking JNI. I think this is good material for a future blog post - "defining interop".
Mea culpa John. Gotta go find me a little chocolate.
No comments:
Post a Comment