I like to think of polyglot programming the same as construction. I have a fairly standard set of tools for doing work around the house. While doing some remodeling recently, I needed to attach some 2×4s to the concrete floor. Now I could have accomplished this with the tools I had, but it would have taken quite a bit of time and the result would have been questionable. Instead, I rented a stud driver that uses .22 caliber shells to drive the nails through the wood into the concrete at one time, and it was fun to use to boot.

Now this stud driver was a standard tool, although not one I own. There was an extra cost involved, both in time and money, to use this tool, but the results were better. The same analysis should be performed before adding a new language into the mix. Will the result be better and easier to maintain, even with the cost of training developers in the new language? Sometimes, the answer is yes and sometimes no. If the new language will cut out a large chunk of code, then it there might be a good argument. How much is a large chunk? 100s of lines of code eliminated. If you think about what using SQL versus writing raw database IO saves you, you will see my point.

On the other hand, there is the “shiny” problem. Programmers will want to use the latest and greatest, not because of the great saving, but just because it is new and interesting.

In summary, those responsible for a project are already open to the idea of multiple languages, but they should also be wise in evaluating the use of a new tool. If a language is not already well-established and of great benefit, it should not be used. If there is a great benefit, then it should be embraced.

Likewise, when using additional languages, the costs need to be weighed.

You will not rest until you’ve proved me wrong about this being easier to do in an external runtime over HTTP. Someone should rewrite all of these in Scala and end the debate! (Several people have made nice regex wrappers; I don’t know if anything is in the stdlib tho.)

You make a good point though that if folks start making the assumption that doing a project in Lisp, Factor and OCaml is OK, then they are dreaming. Web development uses different language because the problem space has required it.

I have worked in a large corporate IT environment where Java, C++ and C# hold sway. In that environment a shift in management usually means the introduction of, what the proponents consider, a radical new technology strategy. What this amounts to is a functor to take the code base from one of the above languages to another. This is the world where polyglot programming is an anathema.

But if one allows best tool for the job to drive technology selection and the functionality can be encapsulated and made accessible it should be relatively easy to either maintain or replace; it will likely be re-factored or replaced in any case and it is in all our interests to expose the one trick ponies of this world to a thoroughbred horse, once in a while.

And some languages are “closer” than others. Knowing Java makes it easier to pick up a JVM language because you can make use of the platform. And Groovy in particular is extremely accessible for a Java dev; Scala perhaps a bit less so.

You mention that projects will consist of many languages. For the same reason most software projects don’t use dozens of libraries, most projects will also not use that many laguages, there’s no added value. However, I’m sure that you would also not question to use libraries in the proper situation. Well, DSL’s can be interesting subsitutes for those libraries.

To be idealistic for a moment, though: much ballyhoo is made about Paul Graham’s statement that using Lisp for Viaweb, his web store startup that became Yahoo! Stores, gave him a strategic advantage. He has extrapolated from his statement that using a niche language for a project – albeit one that is suited for the problem domain – is an advantage, in that you have to hire smart people for the project, who will help you succeed. He’s not incorrect. For many companies, that idea is not a great one, in that they couldn’t afford to hire 10 or 20 people who, frankly, are good enough that they not only know two or three languages, one of which is obscure, but also want to know more and are capable of quickly learning more.

For a young company seeking an advantage, though, polyglotism is not a terrible idea: it forces you to find the best developers. This may be expensive – although I’d argue back that the best developers could give a hoot about money, given a decent wage and a chance to learn – but it’s an amazing advantage.

“If I add a fourth language – for example, Haskell – I’ve now narrowed the field so far, that it’s doubtful I’ll find anyone capable of handling all aspects within a reasonable price range. ”

I have heard that every public Haskell job posting attracts hunderds of applications, and perhaps several dozen good ones. The #haskell channel in Freenode is one of the largest (if not the largest) language channels.

I know I personally would at this point accept a Haskell coding job at a relatively low price, just to get some real world experience with that beautiful platform.

And I don’t think I’m the only one with similar thoughts. So the claim that Haskell = no workforce seems very much bogus.