Unnecessary skepticism about scripting languages

After the last CZJUG meeting, we discussed using scripting languages and I was surprised by how skeptical everyone was.
Scripting Languages in Java — What Do We Do with Them?, on Blog o javičce, captures some of that skepticism. I’ll try to dispel a little of it.

Sometimes Java and a scripting language are so different that you can’t implement something at all in certain languages, or can only do it with less-than-ideal code. Java annotations come to mind, for example.

It’s a mistake to think of scripting languages as a substitute for Java. They make a good complement to it. I’ll come back to that.

Applications take more work to maintain. It used to be enough to know Java. Now I need to know at least one more language.

True. But how much does it cost to hire someone who knows J2EE Java, compared with someone who can handle JavaScript, for example? I’ll leave the answer to you…

People often point out that a scripting engine on the JVM performs worse than the native engine alone, because of the checks and conversions between the two worlds. This doesn’t quite apply to Groovy, for example, which is just a different kind of Java.

In the words of a classic, Intel will solve it for us.

So what would I use it for? I can imagine writing some parts of an application faster in Groovy, for example. Maybe I’m too conservative, but I don’t see that as much of an advantage. I like my Java :), so I’ll write it all in Java. Looking past my own preferences, maintenance matters a lot. Adding languages and technologies makes it harder, more complicated and more expensive. If I’m writing part of the application in a scripting language anyway, why not write the whole thing in that language?

I like my Java too, which is exactly why I welcome scripting languages. Back to facts. Let’s start with the big picture. Have you ever asked what’s behind the rush to adopt new syntactic sugar? I think it’s the efficiency of other languages. One of Java’s greatest strengths as a language was its conservatism and simple syntax. Extending Java’s syntax gives up those advantages. It makes more sense to let scripting languages fight the battle for efficiency and work alongside good old Java on the JVM.

Scripting languages don’t suit every kind of task. Take a system that needs to be customized to customer requirements.

• Build a core that provides the system’s key capabilities, whatever the customer asks for. It’ll probably handle data access, transactions, auditing and so on. Implement it all in Java.
• On top of that, build a framework that implements the outlines of the basic use cases. Give it extension points for adding to or changing behavior. At this level, the language choice could go either way.
• A scripting language is an obvious choice for the extensions themselves. A consultant can write one without carrying a pocket guide to Java. There’s no complicated setup, deployment, compilation or other tedious work getting in the way. The language lets you focus on the problem without the complexity of exception handling, database access or synchronizing access to data. Today’s IDEs also give scripting languages good support.

A general use for scripting languages is building DSLs (domain-specific languages), for which they’re far better suited than statically typed Java. Think about which part of your application is essentially a DSL, then ask whether a scripting language could express it more efficiently. The choice won’t always be obvious, but it’s a simple way to decide where a scripting language fits.