2009-08-07 / 16:05 /

(A comment gone long, I decided to turn this into its own post)

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.”

Robert Fischer, We Aren’t Too Stupid for Polyglot Programming

I think Robert’s absolutely right in that we use many languages all the time, the questions are 1) why and 2) is it the right thing to do.

In my experience, polyglotism falls into a few patterns:

  1. Low level + scripting language driver (C + Lua)
  2. Frontend + Backend (Web)
  3. Core product + automation (Make, perl)
  4. Well establish DSL + general language (SQL, regexps)

In all cases polyglotism provides some obvious benefit. For the first two, that benefit is that it allows the project to work. If Lua were fast enough and Ruby ran in the browser… For #3: mixed language automation is an artifact of low-level languages. Make is a good build tool for C but Ruby’s build tool is Ruby (Rake). Given a change in technology and the right language, these could all be monoglot.

In the last case the DSL’s are chosen for convienence: SQL is better than hand B-tree manipulation and regexps better than FSA‘s.

Using multiple languages isn’t without cost. An obvious one is that learning languages is hard. Most developers know SQL but how many are good at tuning queries? Knowing a language also isn’t the same as fluency. Until you’re fluent in both languages, you’re likely to favor one. See the object/relational–not to mention FP/OOP–divide for examples.

There’s also the technical costs in translating data. XML, Protocol Buffers, Thrift, etc. are all valid interchange formats, but they’re not free. Robert’s emphasis on JVM languages does ease this hurdle, since I believe all the JVM languages can pass objects.

Finally there’s the cost of tools & debugging. You now need tooling–compilers, debuggers, syntax-aware editors–for several languages. More languages can lead to more complexity. Making matters worse, error messages across language boundaries are often cryptic, even when both languages are on the JVM.

So should we all be polyglot? As a matter of personal improvement, I’m all for learning new languages & techniques. But in terms of actually writing good software quickly, it probably only applies if

  • There’s obvious, quick benefit
  • There’s a clear separation
  • None of the other costs are too high

Personally, I think the big efficiency gains are in monoglot solutions. In the web world, glot-supremicists–i.e. Lisp and Smalltalk–have come up with some interesting web frameworks. Polyglotism is a fallback when abstractions leak.