4 July 2007 - 18:09Java and dynamic languages

I was watching this presentation by Rod Johnson on infoq when I came across the part when Rod Johnson started talking about using dynamic languages in a Java application. The main reason that he gave for using dynamic languages in a Java app was that due to pushing the core business logic into domain objects the service layer becomes very thin, “script-like” as he called it. Rod saw an advantage of using dynamic languages (DLs) in implementing the service layer as a series of scripts, I interpret his take correctly.
This is an interesting proposition. I find it a bit off-the-wall and at the same time very timid, which is telling about how DLs are currently treated in the Java world. There is a bit of fear about using DLs, stemming mainly from the lack of exposure to them, like working with any other thing that you do not know you are bound to make mistakes and the fear that getting too involved with DLs may cause some very costly mistakes is present. At the same time you fear being left behind while the rest of the computing environment embarks on these popular DLs, you may be missing out on the next great thing (BTW, the next great thing is very rare). This could sum up the attitude that Java developers have towards DLs: DLs are pretty interesting things, too bad I don’t know how to work with them.
I decided to write this post in order to correct a misconception that most of the people writing about DLs have: that DLs are all about capabilities which are encapsulated in a language. I think that DLs are about their capabilities, but, just as importantly, about the workforce coding in such DLs and I find that scripting example put forward by Rod Johnson fits this statement.

One big problem that using a DL in a Java application is the exposure that the developers using it had to that DL. You will find that most developers will absorb a foreign language only so much, and will tend not to get too deep into it unless it applies heavily to their tasks. You will also find that getting to know well a DL requires quite a lot of effort, effort that most developers are not willing to put in. The correct use of a DL being related to the exposure to that DL it follows that you cannot really use a DL’s more sophisticated features and that you will also try to avoid developing complex constructs in a DL. The scripting example becomes very telling right now, because scripts are nimble little things which do a very small and simple task, I would say that this type of tasks can be coded by a regular Java developer in a language that it cannot master completely. I would even venture to say that because of high costs of adopting a DL DLs will never get beyond simple nimble things in the Java world. I am not so sure about coding the service layer in scripts though. Will the service layer dwindle in complexity to the point where you could script it up? I am not so sure, time will tell.

P.S. A possible case for domain-specific-languages: A while ago I was talking to Derek about Erlang, a language developed by Ericsson for dealing with concurrent. I am wondering if it would be better to find a way to insert Erlang into a Java application in order to manage concurrency by writing Erlang programs instead of populating Java with various concurrency constructs. If your application is using hard-core concurrency it probably has some developers which may have had some exposure with Erlang. Your application may be more manageable if concurrency is coded in a language dedicated to manage concurrency.

P.S. 2.0 The costs for adopting a DL are the costs of adopting any language, in particular a domain-specific language (DSL). These costs are roll-back costs (you cannot roll-back a language out of an application so easily), training costs (the work-force needs to be trained in this language) and human resources costs (if you happen to choose a language which is not considered cool anymore you may end up having recruitment problems, who wants to work on something perceived as a dinosaur?)
This would explain why developers have the same reaction to DSLs as they have to DLs: a bit of fear laced with excitement.

P.S. 3 I wrote this post in a hurry, I think it shows thru.

Later Edit: It would be interesting to see that now with scripting languages moving into JEE applications whether JEE applications will be used by developers using scripting languages. If Rod was right in his assumption that the service layer could be script-ed up it is conceivable that a Java app could be picked by a Ruby shop that would modify its service layer as it fits its needs. I don’t see this happening because the Ruby people would have minimal control over the app in this case (in this scenario they would have control only over the service layer, even though in theory it is possible to plug Ruby business logic beans into the original Java app via Spring) and because it would require that the Ruby team has some exposure to a Java application deployment environment (Spring files, etc…). Again, it requires that a set of developers (Ruby developers in this case) has some exposure to the other language and environment (the Java application) with all the problems that this implies.
Later Edit 2: Today I read about an interesting case of scripting: JRuby GUI APIs. What I find interesting about coding GUI in Ruby is the fact that it lowers the barrier of entry to coding them to scripting, a coding style that is much closer to a graphic designer than your typical Swing event handlers. Who knows, maybe the future desktop designers will grok JRuby…

Later Edit 3: This is an interesting article on integrating Erlang and Java. While it doesn’t show you how you could code access to various beans in Erlang it is interesting.