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.