What do folks mean when they speak about polyglot programming? They mean using more than one language to solve a problem. Usually they are talking about larger projects, often denoted with the moniker "enterprise". Many large projects do this already, they use SQL or some type of ORM (often with it's own language) to communicate with the database, a language with great front end libraries like JavaScript or Flash, glued together by a general purpose language like Java or C#, built by something like Rake or Ant. There are many other configurations worth considering but the above mentioned design is common enough that we'll focus on that.
I've heard that the above approach should not be considered "polyglot", because you "have" to use different languages. That's like arguing the sky is blue because it "has" to be. The sky doesn't have to be blue, it is blue. Enterprise programs don't "have" to be built with multiple languages but they often are. People have found advantages to embracing the polyglot approach to large scale projects.
The confusion often comes in regarding the middle layer. If it is built in language X, should language Y be introduced? Without knowing anything about the nature of the business, the problem being solved or the team solving it the answer is obviously no. Introducing a new language will make it too difficult to move programmers around the codebase, new talent may be too difficult to find or train, and language Y does not offer enough of an advantage to validate its presence in the project. I don't even have to name any languages here, there are many folks who hold these truths to be self-evident.
As someone who makes money contributing to the design and implementation of enterprise software I can only hope that my competitors are the ones who take this "one size fits all" approach. Instead of focusing on the languages focus on the business. We are always trying to find the right balance of fast, good, and cheap. Here are a few questions to consider:
- How much value does language Y add in solving the business problem?
- How important is it to solve the problem quickly and with a highly flexible solution?
- How easy is it to isolate the solution to in the codebase?
- Do you have folks who can come up to speed quickly in language Y?
My issue with posts like this is there isn't a one size fits all solution to enterprise development. The author makes some good points and I have little doubt that the way folks used multiple languages on his project was a problem. However, the author's experiences don't translate to a universal rule for all enterprise projects. I suspect that if the folks that introduced Scala into the project limited its use to a specific area of responsibility or layer and limited the use of more difficult parts of the language then his blog post would have looked a lot different. Just because a language has advanced features doesn't mean you have to use all of them. Good technical leadership should be able to determine a solid combination of languages and libraries that allows the skills of the team to solve a problem.
"Stick to the lowest common denominator languages so it is easy to staff projects." You have now just sacrificed fast and good for cheap. You didn't even pick two! Is that the right business decision for your project? Would your stakeholders agree? I'm sure some would. I'm sure some would not.
When you look further than a project and you are trying to maintain a quality development team there are other considerations. Why are Macs gaining popularity in the enterprise? Why are folks looking at languages like Groovy, Scala and Clojure? Better developers want to use expert tools. They want to accomplish more in less time and be able to respond quickly to changing business requirements. They want to come as close as possible to delivering fast, good and cheap. On the JVM Java is well past its prime. Great for integrations but bad for most projects. Are there exceptions? Sure. I suggest Java for things like embedded systems and highly optimized code. For everything else there's often a much better choice. For example, Groovy is often an easy jump for Java developers and can help folks to deliver business value quickly. After spending some time working with Groovy I noticed I was spending more time thinking about how to solve the problem and less time setting up the plumbing. I've had fairly similar results with Clojure and Scala, more business value can be delivered in less time with greater flexibility than Java. However, it can be fairly difficult for developers to get up to speed with these languages. Depends on the team, your mileage may vary.
For more information on where it makes sense to apply the polyglot approach Venkat Subramaniam does a great job explaining things.
Use common sense and experience to determine the right tools for the job. There is no one size fits all solution.
Thanks to liangjinjian2005 for the photo of folks shaking hands.
