Neal Ford, the guy directly responsible for my career (yes, all legal claims need to go his direction), has on his Meme Agora blog, numerous conference keynotes, and various podcasts has pushed forth the idea of Polyglot Programming. The basic idea behind Polyglot Programming is that various aspects of a computer program could be written in multiple implementation languages that target a specific platform. More specifically think of all the computer languages that all run on top of Java’s VM and choosing a few from that set for your application and you’ve got the idea. You would choose what to use based on what language could most easily solve the problems related to a specific aspect of the application. For example, on a JEE web application you might write the view in Ruby on Rails running on JRuby, implement the controller layer in Groovy code in Spring, and use plain ole Java for the model because you have 90% of it already written for a previous application.

Neal uses an example I thought I’d expand on to make the point of Polyglot Programming. Think of Java as wood; you know, the stuff they get from trees. You happen to be a structural engineer that is involved in building buildings. Now imagine that no matter what type of building you were asked to build you used wood. For a large number of building types that would be just fine. But then you’d run into limitations of the material. Say someone says they want you to build the world’s tallest building. Breaking out the tried and trusted wood wouldn’t get the job done. You’d have to use a wide range of materials each targeting a specific need of getting the skyscraper built. The idea of using one material all the time for all problems seems almost insane, doesn’t it?

At first, I thought Neal had gone farther off his rocker because there would be no way that you’d be able to sell the Polyglot Programming idea to an organization that already had 500 Java programmers and 100 .NET developers that has been cranking out projects for years. Asking to toss into the technology stack another 200+ languages that run on the Java VM and who knows how many for the CLR is a bit much. On top of that, through my personal experience trying to staff development teams, I’ve found that finding developers that have a reasonable understanding of Java let alone knowing anything about Ruby, Groovy, or Jython is an incredible stretch. Add those together and while I thought the idea of Polyglot Programming was a good concept I didn’t think it would survive in the “real world”.

Thinking about it a bit more I realized that I’d already been doing a form of Polyglot Programming for years. Sure, I wasn’t throwing different languages at the JVM but I have piled JSF, Spring, and Hibernate on top of Java/JEE to produce web applications. Each of these frameworks adds a DSL-like layer to the application’s technology stack. Each is already adding to the cognitive load that a developer has to understand to be effective on a project. I am already asking developers to know something more than just Java/JEE or even the Java platform. I am already adding to the technology stack of the organizations I work for. Thinking about it in that light putting the idea of Polyglot Programming isn’t that much of a stretch.

Targeting a specific platform and relegating the programming language choice to what the language can do for you to solve your problems instead of just defaulting to some generalize programming language is an incredibly powerful idea. Being able to alter the tools you’re using over time while not having to go back to re-write legacy applications because you aren’t moving off of the target platform can save organizations lots in development costs.

So, I’m just left wondering where the hidden costs in Polyglot Programming are.

Leave a Reply