There has recently been a surge of interest around polyglot programming, which refers to the use of more than one core language in the provision of a software system.
Polyglot programming has been around for some time. An often-cited (but somewhat misguided) example of polyglot programming is the mix of SQL and programming-language code. This does not constitute true polyglot programming, as SQL is really a domain-specific language for persistence as opposed to being a direct contributor to the core, functional requirements of a system. The key differentiator is that SQL is not Turing-complete; perhaps then, the better definition of the modern sense of polyglot programming is where more than one Turing-complete language contributes to core functionality.
But alas, even 'Turing-complete' polyglot programming is not new: consider (for one) the old Microsoft architecture of Visual Basic front-ends talking to C++ COM objects on the back-end. So, what change has taken place that fuels the interest in polyglot programming?
The change was that ever-increasing bandwidth and computing resources conspired to enable text-based protocols to become a reality: gone are the days when arcane binary protocols were a pre-requisite to efficient distributed systems. Text-based interoperability began with XML/SOAP-based web services and continues with RESTful architecture implementations and other, 'smaller' protocols including Atom and XMPP (for example).
This new breed of interoperability technologies affords far broader opportunities for the development of heterogeneous applications simply because the payload is formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and at no time in the past has this been more possible than the present. Text-based interop has blown the doors off what was previously possible, the impact of which is largely underestimated.
Architects can now combine specific, powerful tools in the provision of software that move the yardstick from previously being able to employ the right language to now being able to employ the right paradigm. As an industry we are just beginning to see this effects of this; there has been a combinatorial increase in the technology topologies of modern systems. This is not just a reflection of their diversity, but is a testament to new possibilities.
While choice is not always a good thing, it is 'less worse' than the alternative in the context of architecting modern software systems. As an industry, we are faced with very serious problems, and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them.
Your job as architect has become even more challenging, because technology silos are crumbling in the face of the new interoperability; embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.
This work is licensed under a Creative Commons Attribution 3
 - Many architects prefer the RESTful architectural style over SOA, because most SOA implementations ended up being the architectural equivalents of old-style RPC, the only difference being XML as the payload format as opposed to some binary protocol. The tooling around SOAP will be its ultimate undoing; the stubs and skeletons creates code smells that hearken back to an RPC-centric view of distributed systems. Thus, many architects and designers were led into the trap of designing systems as they were used to. Design best-practices such as document-oriented SOA was not adopted, understood or applied on a wide scale.
 - _The Paradox of Choice - Why More Is Less_, Barry Schwartz
 - The incumbent multicore era will prove to be the most significant problem yet faced by the software development community.
 - The Free Lunch is Over - Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm
Back to 97 Things Every Software Architect Should Know home page