Let me start this blog post with a disclaimer: I’m really convinced of the value of multilingual programming and also think that applying the “right tool for the job” is a good thing. But there is a fallacy around this concept in programming that i want to point out here. The fallacy doesn’t invalidate the concept, keep that in mind.
Polyglot cineasts
Let me start with an odd thought: What if there was a movie, a complicated international thriller around a political intrigue, playing in over half a dozen countries. The actors of each country speak their native tongue and no subtitles are provided. Who would be able to follow the plot? Only a chosen few of really polyglot cineasts would ever appreciate the movie. Most of us wouldn’t want to see it.
Polyglot programming
Our last web application project was comprised of that half a dozen languages (Groovy, Java, HTML, CSS, HQL/SQL, Ant). We could easily include more programming languages if we feel the need to do it. Adding Clojure, Scala or Ruby/JRuby doesn’t sound absurd to us. A programmer capable of knowing and switching between numerous programming languages is called a “Polyglot Programmer“.
The main justification for heterogeneous (polyglot) projects often is the concept of “using the right tool for the job”. The job often is a subtask of the whole project, like building the project, accessing the database, implementing the ever-changing business logic. For each subtask, some other language might outshine the competitors. Besides some reasonable doubt concerning the hidden cost of this approach, there is a misconception of the term “tool”.
Programming languages aren’t tools
If you use a tool in (basic or advanced) engineering, let’s say a hammer to drive some nails into a wooden plate or a screwdriver to decompose your computer, you’ll put the tool aside as soon as “the job” is finished. The resulting product (a new wooden cabinet or a collection of circuit boards) doesn’t include the tool. Most of the times, your job is really finished, without “change requests” to the product.
If your tool happens to be a programming language, you’ll produce source code bound to the tool. Without the tool, the product isn’t working at all. If you regard your compiled binaries as “the product”, you can’t deal with “change requests”, a concept that programmers learn early and painful. The product of a programmer obviously is source code. And programming languages don’t act as tools, but as materials in this respect. Tools go away, materials stick.
Programming languages are materials
As source code is tied to its programming language, they form a conceptional union. So I suggest to change the term to “using the right material for the job” when speaking about programming languages. This is a more profound decision to make in comparision to choosing between a Phillips style or a TORX screwdriver. Materials need to outlast when the tools are long put aside.
But there are tools, too
In my web application example above, we used a lot of tools. Grails is our framework of choice, Jetty our web container to deploy to, the Spring Framework provides mighty utilities and we used IDEA to bolt it all together. We could easily exchange Tomcat for Jetty or IDEA with Eclipse without changing the source code (the example doesn’t work that easy for Grails and Spring, though). Tools need to be replaceable or even disposable.
Summary
The term “the right tool for the job” cannot easily be applied to programming languages, as they aren’t tools, but materials. This is why polyglot programming is dangerous to when used heavily in a single project. It’s easy to end up with a tangled “amalgam project”.
Two more disclaimers:
- If chosen right, “composite construction” is a powerful concept that unifies the advantages of two materials instead of adding up their drawbacks.
- Being multilingual is advantageous for a programmer. Just don’t show it all off in one project.
Schneide Blog 
Right tool the the job is something I rarely hear anyone but Java programmers say. They say it because everyone has a special tool, language, library they like and prefer over another one. When I was doing C++, C++ was the right too for the job. And I was doing ASP, it was the right tool for the job. .Net developers will never concede that Java is the right tool for any job and vice versa. Developers simply need to stop saying this.
Thank you for the comment. If I understand you right, you basically say that “if you (only) have a hammer, everything looks like a nail”. That’s the problem polyglot programming initially tried to solve – by saying that projects may consist of source code written in multiple programming languages without being regarded as an inferior mongrel.
But I can wholeheartly agree to “developers simply need to stop saying that their specific tool/language is better/the best”.
For me an application should be built with a stack most suitable but if there are other apps needed to support it or the likes then each of those should use the most suitable stack. Just because language x was used for developing a web app that doesn’t mean it should be used writing tools to work with the server cluster.
Although this brings up an interesting point. A language isn’t really a tool but can make them. *shrug*
material not tool, like it! thanks
Excellent article. I think calling a language the “material” is a much more fitting metaphor. Gregory a language isn’t a tool and can make them the same way wood and steel aren’t a tool but can make a hammer.
i agree with the critique to the language-as-tool but i dont like your alternative (it fits your dislike with the polyglot programming) Why not prog-lang as languages (or slangs) like your film comparation? but i’d use the metaphor in other way: if the computer (and other programmers) understands you better in lesser words and you have to say much about a specialized task perhaps worthwhile to choose a language (o dsl or a framework build on top a lang..i dont see radical differences)
Hi jneira, thank you for your comment. I can see your point, it’s a valueable addition.
There is just one thing that I want to clarify: i have no dislike for polyglot programming. You probably skipped the first paragraph with the disclaimer in it and forgot about the third one.
I clearly see the value of polyglot programming and I use it to my advantage. But it isn’t a silver bullet and drawbacks exist. That’s what this blog entry is all about.
Your whole basis of a post betrays an ethnocentrically US blindness towards multiple languages. Having lived in Germany for a while, I’ll tell you that the people around me rapidly slipped into Deunglisch—a kind of English/German hybrid where the right language was chosen for the right context. You see the same thing in all kinds of multilingual contexts throughout Europe—presumably through the rest of the world, too, although I have no experience beyond the US and Europe.
For an easy experience of this reality, read practically any classical European Enlightenment, Romance, or early Existentialist literature, you have the use of multiple languages all over the place. These writers expected their readers to know at least Greek and a smidgen of Latin, if not French and German to boot, and so even purportedly English texts are shot through with alternative languages, sometimes at a fair bit of length.
The assumption in your initial example is that only a few people would be able to understand the movie—yet the very claim of polyglot programming is that we need to be realistic and realize that developers know many different languages, and so we need to start being conscious of our language choices to leverage that reality.
Now, languages-as-tools and languages-as-materials is ultimately pretty pedantic based on conceptual differences between “tools” and “materials”. Use whatever metaphor works best for you—the point is that polyglot programming is a powerful way to more quickly develop more maintainable code, not to mention a powerful way to improve your personal skill and value as a developer.
I agree with Abrand: “material, not tool” is a brilliant analogy, and I’m totally going to steal it. 🙂
Brilliant viewpoint, however, I have a little thing different. Yes, the language is a kind of material. What’s kind of the framework, or the library. I think it’s fill with complexity in programing, and programing is a process to solve them rather than to destroy them. How? with suitable language, or framework, of library, or all by yourself. I don’t think the others can’t make some benifit. I think learning a DSL is not more difficult than learning a framework or a library or implementing all.
At last, as you said, it’s unnecessary to use too many generate langage in a project.