In my previous two posts, I described my experience with maintenance and refactoring on a large project that used both Java and Groovy. In this post, I will discuss the installation concerns raised by Bill Burke in his blog post “Polyglot programming is the worst idea I ever heard”.

In describing the “installation nightmare”, Burke states:

But you still need to package and install all the appropriate Java libraries, Ruby gems, and Python libraries on the appropriate places of your user’s machine. You also need to hope that all the desparate environments don’t conflict with anything the user has already installed on his machine. And that’s just with languages running in the JVM.

These are valid concerns, but I don’t think they are exclusive to polyglot programming.

The problems of developing code that “works on my machine” but doesn’t work anywhere else are well documented. In my opinion, the first place to start with any project is a one-step build that provides for automated testing plus some form of continuous integration. This isn’t a particularly original idea these days. In our project, we used Ant to implement a one-step build using a clean checkout from version control. It took effort to get this working, but the effort involved would have been required whether Groovy was involved or not. In my experience, migrating from desktop Windows to Linux and then to AIX became a non-event once I had a one-step build in place.

In response to my previous blog posts on this topic, it has been pointed out that Groovy might be a special case. This is true to some degree in that Groovy was designed from the beginning for easy integration with Java. However, I think the concern about conflicts among libraries on different platforms is valid with or without Groovy. I’ve experienced first hand the unexpected differences in string truncation among IBM’s DB2 drivers running on different platforms. On Java projects, there is always a concern about a conflict with Antlr or ASM when using Hibernate and some other library that uses byte code generation. Adding Groovy is no different than adding any other library or framework to a project. There are always risks. Fortunately, one step builds and continuously integrating on all of your project platforms are tried and true strategies for mitigating this risk.

Finally, my thoughts with regards to non-JVM languages are different than those expressed by Mr. Burke:

Imagine if you used vanilla Ruby, Python and Java all as separate silos!

I would encourage you to take your imagination out of the decision making process and base it instead on facts by testing things for yourself. For example, with Python, you might find that not only is it already installed on your test and production platforms, but your required libraries might be there as well. It also might be that installing the required libraries is trivial. Of course, it is possible that it is not trivial. The important point is to try it out and then evaluate the cost/benefit to your particular project. If the benefit is replacing 10,000 lines of the most complicated part of your project with 2,000 lines of code that is more readable and easier to “reason about”, then even the extra effort of engaging your infrastructure team to install a required Python library might be worth. Remember, the costs don’t exist in isolation but in relation to the benefit of adding another of language. The importance of this cannot be overstated.

At the end of the day, the business doesn’t exist for IT’s benefit and comfort. It is our job as developers to deliver systems that represent a good value to those making the investment. Where appropriate, we shouldn’t be afraid to utilize more than one language if it adds value to the project and take advantage of techniques like one-step builds and continuous integration to mitigate the risks.

In my next post, I’ll address the “support nightmare”.