Why Polyglot Programming is a Fad

One of the considerations when building a new software product is the programming language or languages to use for development. Programming languages can be taken for just tools, like a hammer; one uses them to construct software applications. But more so, they are part of the software’s infrastructure: unlike a hammer, one cannot move to use a different tool on a whim: high switching costs are required.

A few years ago, the concept of polyglot programming has gained momentum and mind share. The idea was that one could develop software using multiple programming languages, all glued together, each optimized for a piece of the puzzle. The idea was largely enabled by the two major platforms (Java and .NET) including  support for language interoperability via virtual machines. People could program in multiple languages and still connect them together without clumsy inter-language binding mechanisms.

What’s interesting is that the concept has recently gained momentum again with the resurfacing of Java-based languages such as Groovy, Scala and Clojure. Half of a recent book, “The Well-Grounded Java Developer”, is dedicated to the concept; people now argue that “no one language will rule the cloud” and that “the future [is] polyglot programmers”. But, there are fundamental reasons why the concept never took off, and never will.

It’s not about Programming, It’s about Software Development

In my far past, I taught core programming in the academia. Stack data structures were one of my favorites. But the reality is that most software developers spend very little time coding data structures. In fact, most software developers nowadays spend little time coding at all. Software developers are expected to learn new libraries and software packages, to troubleshoot and debug, to experiment and test (their own code, and other people’s code), to configure and install software. Less time nowadays is spent on pure coding, simply because much of applications’ infrastructure is already there.

Consequently, the language a developer codes in becomes less important than other factors such as the depth of the underlying runtime environment, the richness of the ecosystem, the power and ease of the development tools, the convenience of the deployment tools, and so on.

Sure, you can shave a few points off the net coding time by using a second language, which may be a better fit for one given task, but you’re unlikely to obtain an environment as productive as using the language you use for your day-to-day development.

Programming in One Language is Hard Already

Well, for most human beings, it is. Or else, software programming would not have been a high paying job. Mastering one programming language is hard and time consuming. Mastering the development environment, the libraries, the ecosystem and the tools around the language (build tools, test tools etc.) is even harder. Keeping up to speed with the changes is a challenge in itself.

Add another language to the mix, and you’ve restricted yourself to geniuses-in-residence. This may work to develop the perfect stack data structures, but can it work in scale?

Programming in Functional Languages is for Freaks

Sure, lambda expressions are fun. So are gamma rays. And Eplison Calculus. But, try to explain any of those to young kids. Advocates of polyglot languages typically have examples showing how concise and pretty a certain computation can be using a functional language. This beauty, in their mind, justifies using that great language in some pieces of the software.

The reality, however, is that it only takes a regular human being to read and write imperative constructs (even if combined with objects). Well, we’ve all learned it as babies, when our parents told us to sit down. In contrast, it takes a beautiful mind to read and write constructs in functional languages. Concise and pretty, sure. Pragmatic? Not really.

Programming in Dynamic Languages is for the Reckless

Sure, dynamic languages are cool. Take away compilation, yank type systems—now you can change code on the server without the need to bother with a nasty compiler complaining about spelling mistakes, or unit tests failing. In some cases, it even works. Please, can I add at least some of that into my project? Please?

Markets Change, People Change, Simplicity Wins

The reality is that large-scale software projects tend to evolve. Agile development, as an example, is all about supporting this realization from a planning and project management perspective. An important side effect to this realization is that the nature of one’s solution changes as well. A product that was designed for the enterprise may now be required to be tuned for small businesses, demanding different scale and different components. First-wave developers may go away, and be replaced by new team members. What keeps the engine going is consistency and simplicity (check out a recent article in Harvard Business Review: Want to Build Resilience? Kill the Complexity). Bring in multiple programming languages, multiple methodologies, multiple tools—and you’ve created a monster.

A Word of Summary

In the end of the day, a programming language is one component of a software product. You can develop a great software product using poor programming languages; you can develop a horrible software product using the best programming language and tools around. But, like any other element, making the right choice can help odds of success.

We hear people advocating the need to use  “better” languages and interweave them with mainstream languages. In many cases, advocates are very smart people who do not realize the barriers-of-entry to ordinary people and the resulting scale and complexity issues. In some cases, it’s people who haven’t gone through a previous hype cycle of new and revolutionary languages. Does does anyone remember ML?

This is not to say that there are no valid cases for using multiple programming languages in one project. There are cases where practicality dictates so (using a different language for client-side programming and for server-side programming is an obvious example in web development). There are cases where plug-in developers (one’s customers) may be expected to write code in a more dynamic language than a platform provider. There are cases where rapid prototyping is required. There may be others.

This is also not to argue which language or environment is the best. Is C# better than Java, or the other way around? Regardless of the language itself, there’s a reason why the most popular programming languages are imperative and strongly typed. Care to play around with others? Sure, that’s great stuff, beautiful and very telling. But, please refrain from introducing them to an engineering-based project based on a mainstream language or your polyglot development may end up being closer to a Tower of Babel.

6 responses to “Why Polyglot Programming is a Fad

  1. The point about dynamic languages is quite weak. Spelling mistakes or unit test failing are caught by the interpreter, that is if you run your tests. If you consider a mistake not to run them in java, why is it acceptable in Python/Ruby/etc ?

    Beside, the fast feedback loop should be put into the balance as a strong positive point of dynamic languages. It is trade off vs some type safety. But please don’t paint the world in black and white.

    • Fair point. This post certainly isn’t meant to be an exhaustive analysis of the pros and cons of strong typing vs. weak typing or anything similar. What is black and white, though, in my mind, is that whether one has elected to use one language (say Java) or another (say Python), intermixing two towards in a “polyglot environment” is, in most cases, a folly. So for example, if one has settled for Java as a primary language, one shouldn’t add Python code just because Jython is around and just because a couple of developers really like, love or appreciate more dynamic languages or hate, despite, or throw up at the Java syntax. Similarly (and less commonly) the other way around.

  2. Have a look at the latest version of C#, it is adding more and more functional language features and also support somewhat dynamic programming with the “dynamic” keyword. If you think those are for freaks and reckless, I think you will be in for a world of pain in 5 years when those are mainstream. And that’s not even mentionning everything related to parallel and async programming.

    • Seemingly my muddy crystal ball isn’t showing the same picture as your clear one, so I might be willing to take some risks around being in pain in five years :-)

      More seriously, though, a couple of quick thoughts:

      1. Regarding functional languages: certainly, functional languages enjoy a nice hype nowadays, which pushed the major language providers (C# and Java) to align and join the game. However, reality is that functional languages have been around for a long while: Lisp appeared in the late 1950’s; it was argued to be a breakthrough in the 1970’s and 1980’s, and has practically died. ML (while more academic in nature) appeared in the 1970’s, was advocated as the best thing since sliced bread, and never picked up. Without getting into a whole analysis of programming languages, it appears that functional languages enable great programming riddles, but are less aligned with plain human brains; one of my colleagues calls some of those languages “write only languages”, which captures some of the challenges in such programming constructs.
      2. Regarding dynamic languages: yes, dynamic aspects of programming languages have been around for a long while, too. Visual Basic was dynamic, but then introduced OPTION STRICT (and OPTION EXPLICIT), and most serious programmers developing non-trivial applications used those options to displace runtime errors and leverage compile-time errors instead. So, sure, one can bypass compile-time verification, but my (again, admittedly muddy) crystal ball suggests that even in five years, most serious products will still be written using statically typed languages and language constructs.

      That said, you have a fair point: some good elements of “loose” languages make it and will continue to make it into mainstream development. That’s great, and it’s how technology evolves. As they are, they are integrated into a single develop-compile-test-deploy-debug environment. That’s when one should consider using them (especially if, like many of us, they consider themselves freaks ;-). But, opting for a polyglot development environment just to gain (controversial) benefits such as functional programming and weak typing is simply bad judgment, and will therefore (my crystal ball says) be soon extinct.

  3. “Or else, software programming would not have been a high paying job. Mastering one programming language is hard and time consuming.”
    Mastering drug discovery and development skills is no less hard and time consuming but biologists/chemists are paid thrice less than programmers. I don’t see any link between being highly paid and sophistication of your mastered skills. It’s market structure only.

    • You may be right, but most modern economic models of price structures are based on supply and demand (see e.g., http://en.wikipedia.org/wiki/Supply_and_demand). According to such models, high price structures indicate high demand and low supply. The low supply for (good) software programmers (compared to demand) may be due to other considerations, but the most natural/probable one is the high complexity associated with this particular job (i.e., intrinsic inability of supply to catch up).

      You have a valid point in that other jobs may be as complex, but because demand is so much smaller, salaries don’t reflect the complexity. True or not, I would dare to guess that in such disciplines, the equivalent of polyglot programming (e.g., use multiple tools and processes where one does the job, albeit arguably not optimally) isn’t actively advocated as a day-to-day paradigm.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s