Our Thinking

Polyglot Programming

Posted by Dave Gillies on Mar 26, 2012 9:35:38 AM

Nikon vs. Canon. Cubs vs. White Sox. Java vs. .NET. These debates have polarized camera buffs, Chicago baseball fans, and software developers so fiercely that they have been called "Holy Wars," a tongue-in-cheek reference to the passion and vitriol with which many real battles have been fought over religious differences. To be sure, arguments over technology by name or brand still have their supporters, but I like to think that many of us in the industry have moved past that. I have been fortunate to work with vets who approach problems and projects by first choosing the most effective tool or platform based on their comparative strengths and weaknesses and how those relate to the task at hand. I love this approach, and these are the practitioners I choose to emulate.

In this light, I have been exploring what has come to be known as the Polyglot Programmer, a term I first heard Neal Ford (http://www.nealford.com) use years ago at a conference I attended. Polyglot Programming embraces the notion that combining multiple languages and frameworks to solve the domain problem at hand can yield the most efficient results.

We are seeing this play out in many ways. The two dominant enterprise development platforms, Java and .NET, have both grown to support development in many different languages. The Java Virtual Machine currently supports Clojure, a functional Lisp dialect, scripting languages Groovy, Rhino and JavaFX Script, and Scala, which is both object-oriented and functional. It even supports popular dynamic languages such as Ruby and Python through JRuby and Jython implementations, and aspect-oriented development with AspectJ. A less well-known language called Oxygene, with roots in Object Pascal and Delphi is also supported. These languages each offer wildly varying strengths and weaknesses and allow you to build a system using any combination, all running against the same deployment environment.

.NET brings even more to the table, offering support for no fewer than 50 languages, in categories like those in Java plus more exotic animals I hadn’t heard of such as Nemerie or Cobra, and older, formerly popular languages such as Fortran, Cobol, Smalltalk or Ada. Check out the full list for yourself if you are interested (http://en.wikipedia.org/wiki/List_of_CLI_languages).

More evidence for the polyglot approach can be seen in web programming going back nearly to the birth of the browser. Since Javascript, CSS, and Java applet support was added to native HTML, you'd be hard pressed to find many web projects of appreciable size that didn't mix some combination of these with languages such as XML for configuration and SQL for the database – at a minimum.

I would argue that this explosion of languages is primarily a result of organic growth. Enterprising developers have tacked onto existing environments as needed – and some ideas have caught on while others disappeared. The multiple-language paradigm has snuck up on us, particularly on web developers. I believe that the industry now has a great opportunity to capitalize on this growth by making more tactical decisions about how projects are implemented that can take us to a new productivity level. But we must be prepared, for the story is not all good news.

Certainly, there is a cost to the polyglot approach. Debugging can be harder, testing can be harder. Time spent wiring up all the pieces can be time consuming until it becomes a familiar pattern. Taking the idea too far is a pitfall we must avoid. It’s easy to argue that two or three languages would offer up the tactical advantages of each language without excessive overhead, but it’s even easier to argue that wiring up 10 languages to solve one problem most assuredly is not a good idea!

We must strike a balance. Approaches such as Test Driven Development and evolving build and provisioning tools will help make these approaches easier. There is no doubt in my mind that this area is one to watch.

I believe that taking the Polyglot approach to problem solving and system architecture is one that all developers should be thinking about. I suggest you take a look at the platform you are most familiar with. Are there other languages you could be taking advantage of on your existing deployment platform to be more efficient or to open up new solutions for your clients? Are there certain classifications of problems where your solutions feel forced or don’t quite seem to fit, and you really prefer a more elegant, maintainable and economical approach? Have you considered another language?

Polyglot Programming Resources


Topics: Design, Languages

Our Thinking - The Online Blog is a source for insights, resources, best practices, and other useful content from our multi-disciplinary team of Onliners.

Subscribe to Blog Updates