Standing on the shoulders of giants: say no to proprietary languages, welcome to Groovy and salute JVM

Majority of the tools in the IT management tools marketplace either have a proprietary scripting language, or set of configuration files so complex that become mini languages on their own right, and require extensive "product training" to accomplish anything significant. As a result, these tools are often "knowledge islands". One has to investigate significant time learning them, there are "certification" programs, training classes, etc. and the skills are often not transferable.

We wanted to explicitly avoid this phenomena, hence resisted inventing a new language, or using very complicated configuration files as much as possible, and worked hard at this. As many things in life, this has been harder than we had thought.
Through our journey, we have worked with several different languages and I must admit the urge to come up with our own to meet our specific needs has been strong, but we have managed to resist for the most part :)
The benefits of using a standard language by far outweighs the shortcomings. By using a standard language, (obviously) we don't have to develop and maintain a language on our own, and our users don't have to learn a language syntax that they can only be used with our products. Frankly, being a small company, I think it would have been delusional to think that we could convince people to learn a new language syntax just for our products, but I think it's a bad idea for larger companies as well.

There are a lot of heated discussions on advantages and disadvantages of developing with dynamic (scripting) languages such as ruby, phyton, etc. vs java, the dominant staticly typed programming language used today. For us, the most important benefit of Java is not the language but JVM and the amazing set of software libraries available for pretty much anything one may need. Fortunately, we don't have to choose between the two worlds. There are many scripting languages that work in the JVM, and can make use of the vast number of java libraries available. One can run scripts from a java program, or call java libraries from a script and run the scripts in the JVM. To me, this is just amazing, and we make heavy use of scripting languages in our products.

The primary problems solved by the use of a scripting language in RapidInsight is the ability customize the functionality of the application in the field. Different users have different needs, hence our products needs to be flexible enough to handle these different needs. How can we provide this flexibility? We have chosen using a scripting language over complex configuration files or user interfaces that require training. Our philosopy is to implement a UI for customization whenever it is possible to have a UI users can user without extensive learning process. Most users are familiar with commonly used patterns in administrative tools. If we can implement the functionality in an easily understandable UI, then we opt to implement a UI. And whenever the customization requirements are complex, we choose to include a scripting layer for maximum flexibility rather than using a proprietary language, overly complex configuration files or complex user interfaces. I cannot say that we are there yet, but we're getting there.

By leveraging an existing dynamic scripting language that runs in JVM, we were able to ensure that the solutions based on RapidInsight is simple to implement for simple cases and flexible to handle more complex requirements.

Groovy is "an agile dynamic language for the Java Platform with many features that are inspired by languages like Python, Ruby and Smalltalk, making them available to Java developers using a Java-like syntax."

We chose Groovy as our dynamic scripting language since Groovy:

  • runs in the JVM
  • can leverage existing java libraries ensuring that it can practically do anything we may need
  • has excellent shell integration to work with executables, shell scripts, etc.
  • Compiles to java byte code minimizing/eliminating performance penalty
  • has a versatile syntax to handle most common scripting requirements
  • is moving to become a "standard" language by going through the Java Community Process (JSR 241)

One of the advantages of Groovy is that it is very easy for any java developer to learn as this had been a design criteria for Groovy. On the other hand, the language is a bit verbose and not that intuitive for non developers, which has been the primary down side of Groovy for our needs.

Overall, Groovy has come to play a central role in all our products including RapidInsight. Its seamless integration with java and wonderful flexibility has made Groovy indespensable for us.