Are polyglot systems a good idea?

A recent tweet pointed me to a post on polyglotism by Bill Burke of JBoss. It comes in the midst of a lot of interest in alternative languages on the JVM, such as JRuby, Groovy, Scala, and many others. Its basic point is that companies indulge in multiple languages at their peril and a Java shop should really stick to Java. His view struck me as over the top, but a little reflection made me realise that software teams should take on board his message or risk some serious long term problems.

Now, I’m not a dyed-in-the-wool Java developer who believes Java is the solution to all problems. In fact, I like a profusion of languages on the JVM. Variety is the spice of life as they say. A competitive field ensures that only the strongest survive, and without new languages we would probably still be stuck with C or even assembly language. I want to see new languages that improve my productivity as a developer, enable me to write more reliable code, or simplify the code I write. Even better are languages that give me all three.

So why am I echoing Bill’s warning? Because there is a difference between having a vibrant ecosystem of competing and complementary languages and actually using many of them in a single software project, team, or even company. Here are some of the things you should consider:

Language libraries

Almost every language comes with its own class or function library these days. That’s often the case even when a language runs on a virtual machine such as the JVM or .Net’s CLR. Look at JRuby and Scala: they both run on the JVM but have their own class libraries. So if you use more than one language in a project, you’ll have to know all the various libraries pretty well too.

Context switching

It’s not uncommon to have both Groovy and Java files in a Grails project and developers often have to work in both languages to implement features or fix bugs. That means developers have to switch contexts when they move from one type of file to the other. Even with languages as close in syntax as Groovy and Java, this can cause errors to creep in, for example when you try to iterate over a list in Java using the each() method. Imagine mixing Java and JRuby, where you have different class libraries as well as wildly different syntax.

Certainly a good developer can manage this, and if he or she switches between languages frequently, the cost in time and mistakes will dwindle. But can you guarantee that a developer will always be working in all the required languages at any given time?

Other developers

Just because you can pick up a new language and be proficient with it in a few weeks, that doesn’t mean everyone will be able to do that. If you have a team, you have to take into account the other team members. Realise that some will have trouble learning new concepts, such as functional programming or dynamic languages. Don’t forget as well that using non-mainstream languages shrinks the pool of developers you can recruit from.

It takes time

So, you got the Hello World example up and running followed by the Fibonacci sequence. Great! It only took you a few minutes! Then what? Learning the basics of a language can often be fairly simple, but to become proficient takes time and you have to use it on a regular basis. Can you really afford that time for all the team members on a critical project?

When you leave

As Bill pointed out, development teams don’t always stick together. What happens when you leave? The company is potentially left with a hole they can’t fill because there aren’t any free developers that know all the languages you put into the system.


Last but not least, not all languages play nicely together in a single build. How much effort do you really want to put into making different languages fit into your build system? If it’s not much trouble, then great, but otherwise you could end up with an ongoing maintenance headache.

I don’t mean to dismiss the idea of polyglot projects or systems – a new language may provide real benefits that outweigh the problems. Just make sure that a decision is based on a decent risk assessment or back of an envelope cost-benefit analysis rather than a “hey, that language looks cool, let’s try it out” impulse. Of course, feel free to play around and try new things when you’re working on personal projects!

5 thoughts on “Are polyglot systems a good idea?

  1. Mac

    I think polyglot systems are a good idea, if used wisely. I’ve always been an advocate of “best tool for the job”.

    But imagine a project where you are implementing a grails website using groovy, use java to implement services, use scala to handle message passing because of actor support, use clojure to implement the AI logic to predict the flight delay. Imagine what the code review session would be like.

    The above is of course, a silly made up example. But in my current project, we are in fact using groovy, java and clojure. It has lead to some, uh, interesting code review sessions. 🙂

  2. Bill Burke

    I’m not sure Groovy and Scala fit into my idea that Polyglotism is bad as they are both supersets of Java, no? I was really thinking more of Ruby, Perl, Python, C, C++, Java where they all have different package structures, installation, runtimes, syntax, libraries, etc.

  3. Peter Post author

    Groovy is a special case because its syntax is so similar to Java (as you say, it’s pretty much a superset) and it uses the same class library (the JDK). Those are two of its main selling points.

    That said, it’s a dynamic language and therefore it behaves significantly differently to Java. Developers need to be aware that the compiler won’t pick up type errors, which often causes confusion due to the optional static types. They also have to get used to not being able to navigate to method implementations when they are dynamically added to a class or object. On top of that, it still takes time to learn idiomatic Groovy.

    Scala is very different to Java, even though it runs on the JVM. It has its own core library and it includes functional programming features, which some imperative programmers find very difficult to get their heads round.

    As you say, though, we’re still talking the Java platform in both cases (unless you use the .Net version of Scala), so there are few deployment and integration issues. I think we just need to clearly distinguish between polyglotism (multiple languages) and multiple platforms.

  4. Pingback: Delivering Business Value Through Ployglot Systems (part 1) | Object Partners Inc

  5. Jeremy Flowers

    Polyglot programming seems to a level of complexity too when it comes to compile time. Have a listen to Danno Ferrin on the Grailspodcast 83 when he talks about cross compiling. Effectively when you deal with n languages there’s (2^n) -1 connections between the stubs created for each language. I was making my head spin!

Leave a Reply

Your email address will not be published. Required fields are marked *