We Aren’t Too Stupid for Polyglot Programming

As those who listened to my WebDev Radio interview know, I am working on a book on polyglot programming. This has me asking smart people what they think about polyglot programming, and one of the most surprising pieces of feedback I’ve gotten (from Grails podcast, among others) is that polyglot programming is somehow “too hard”: that developers aren’t smart enough to handle it. This strikes me as an odd complaint.

Polyglot programming, defined most simply, is the use of multiple languages in software development. Although Neal Ford claims to have “accidentally coined” the term, the term predates Neal Ford’s Dec 2006 blog entry: for evidence, see a 2002 Dr. Dobbs article on .Net polyglotism, and a 2004 DARPA presentation on the Babel polyglot support system, which has whitepapers dating back to 1998. So the term itself has been around for a while.

The idea that underlies the term has been around in some form or another since C became the Universal Assembly Language: interoperability with C has always been critical for projects like mod_* (perl, php, rails, caml), which bring non-C code into the Apache web server. Now we’re rediscovering interoperability by having languages interoperate on the JVM. This opens up a new freedom to pick the right language to solve the problem at hand for Java development.

The reality, though, is that we all do polyglot programming all the time. We use command line scripting languages to simplify our lives, and build languages to manage repetitious build processes. In the sphere of web development, we’re regularly working with regular expressions, JavaScript, and declarative languages like XML, CSS, and SQL (or its derivative, HQL). It’s exceedingly common to see jobs looking for developers who can write both an ActionScript front-end and a JVM back-end (Grails, Roo, whatever). I worked at a shop where we used perl for file processing and fed those into a database, just to be consumed by Java batch process. One gig had service calls from Java to .NET in order to interoperate with Microsoft Office products. In none of these cases did the architects sit around and go, “Oh, man, we can’t implement that solution: people are just too stupid to handle it.”

Sure, everyone has a specialty: something they’re better at, and nobody is going to be an expert at every language at the JVM. But recognizing that a particular problem (e.g. highly concurrent processing) is vastly simpler in another language (e.g. Clojure) doesn’t require expert-level capabilities in that language: it just requires familiarity. Writing that solution in that language then becomes an opportunity to learn and develop in that alternative language, and learning a new language isn’t that hard once you’re used to doing it, especially if there’s a more experienced person (or a mailing list!) to help out.

When developers encounter a new DSL, they don’t throw their hands up in the air and declare that they need a specialist in the DSL to code the solution—previous experience, context, and support makes coding this new DSL accessible. The same is true of domain-agnostic languages, but we’ve somehow built up this entire damaging and false sense of identity wrapped up in the language we code: we can sometimes too-closely identify as a “Java person” or a “Ruby person” or a “Groovy person”, and so changing languages means changing identities.

Part of the difficulty is also that the nature of software development has transitioned in large swaths of the industry. As I noted in my ancient The Programmer is Dead; Long Live the Developer! post, actual computer programming is often not the part of the job that pays the bills. The part of the job that pays the bills is understanding how to appropriately tune the O/RM, or knowing how to use the newest and bestest TDD framework, or understanding the particular intricacies involved in deploying to Google App Engine or getting Google Maps to display what you want. Brian’s right, and Programming Doesn’t Suck! Or At Least, It Shouldn’t: but a lot of what developers do these days barely constitutes programming. It’s just configuring and gluing together these bits and pieces in order to get the particular effect we’re looking for.

Given that background, shifting to a new language also seems to imply learning a whole new set of tools and surrendering a lot of hard-won knowledge. And for communities that aren’t used to learning a whole new set of tools regularly (i.e. everyone except the Ruby community), that can be really intimidating. Thankfully, sharing the JVM platform means that you can pull those tools forward in a lot of cases, and polyglot programming specifically means that you can keep using your old tools to do the things they do well, but you can still evolve your coding towards more productive and appropriate languages.

Even better, polyglotism on the JVM means that you can have gradual adoption for languages: if you end up making a wrong choice of language, you can shift off the language and rewrite that code out of existence whenever you have free time; if you know a language is a right choice but don’t know it well, you can write the parts you can handle in the new language and fall back to the old language solutions when things get tricky or novel.

I hope it isn’t too much longer when polyglot development manages to break its way into the mainstream of technical conversation. And I’m saying that as a JVM software developer, not just as a guy writing a book on the topic.

Related posts:

1. Programming Doesn’t Suck! Or At Least, It Shouldn’t
2. Scala is Not a Functional Programming Language
3. Programming Languages are PC OSs circa 1986
4. What is a functional programming language?
5. Why Your Programming Language Is “Too Academic”