Why do you or do you not implement using polyglot solutions?

Question

Polyglot, or multiple language, solutions allow you to apply languages to problems which they are best suited for. Yet, at least in my experience, software shops tend to want to apply a "super" language to all aspects of the problem they are trying to solve. Sticking with that language come "hell or high water" even if another language is available which solves the problem simply and naturally. Why do you or do you not implement using polyglot solutions?

Answer 1

One issue that I've run into is that Visual Studio doesn't allow multiple languages to be mixed in a single project, forcing you to abstract things out into separate DLLs for each language, which isn't necessarily ideal.

I suspect the main reason, however, is the perception that switching back and forth between many different languages leads to programmer inefficiency. There is some truth to this, I switch constantly between JavaScript, C#, VBScript, and VB.NET and there is a bit of lost time as I switch from one language to another, as I mix my syntax a bit.

Still, there is definitely room for more "polyglot" solutions particularly that extend beyond using JavaScript and whatever back-end programming language.

Answer 2

I've been lucky to work in small projects with the possibility to suggest a suitable language for my task. For example C as a low-level language, extending Lua for the high-level/prototyping has served very well, getting up to speed quickly on a new embedded platform. I'd always prefer two languages for any bigger project, one domain-specific fit to that particular project. It adds a lot of expressiveness for quickly trying out new features.

However probably this serves you best for agile development methods, whereas for a more traditional project the first hurdle to overcome would be choosing which language to use, when scripting languages tend to immediately seem "newcomers" with less marketing push or "seriousness" in their image.

Answer 3

I almost always advocate more than 1 language in a solution space (actually, more than 2 since SQL is part of so many projects). Even if the client likes a language with explicit typing and a large pool of talent, I advocate the use of scripting languages for administrative, testing, data scrubbing, etc.

The advantages of many-language boil down to "right tool for the job."

There are legitimate disadvantages, though:

• Harder to have collective code ownership (not everyone is versed in all languages)
• Integration problems (diminished in managed platforms)
• Increased runtime overhead from infrastructure libraries (this is often significant)
• Increased tooling costs (IDEs, analysis tools, etc.)
• Cognitive "bumps" when switching from one to another. This is a double-edged sword: for those well-versed, different paradigms are complementary and when a problem arises in one there is often a "but in X I would solve this with Z!" and problems are solved rapidly. However, for those who don't quite grok the paradigms, there can be a real slow-down when trying to comprehend "What is this?"

---

I also think it should be said that if you're going to go with many languages, in my opinion you should go for languages with significantly different approaches. I don't think you gain much in terms of problem-solving by having, say, both C# and VB on a project. I think in addition to your mainstream language, you want to have a scripting language (high productivity for smaller and one-off tasks) and a language with a seriously different cognitive style (Haskell, Prolog, Lisp, etc.).

Answer 4

The biggest issue with polyglot solutions is that the more languages involved, the harder it is to find programmers with the proper skill set. Particularly if any of the languages are even slightly esoteric, or hail from entirely different schools of design (e.g. - functional vs procedural vs object oriented). Yes, any good programmer should be able to learn what they need, but management often wants someone who can "hit the ground running", no matter how unrealistic that is.

Other reasons include code reuse, increased complexity interfacing between the different languages, and the inevitable turf wars over which language a particular bit of code should belong in.

All of that said, realize that many systems are polyglot by design -- anything using databases will have SQL in addition to some other language. And there's often scripting involved as well, either for actual code or for the build system.

Pretty much all of my professional programming experience has been in the above category. Generally there's a core language (C or C++), SQL of varying degrees, shell scripting, and possibly some perl or python code on the periphery.

Answer 5

My employer's attitude has always been to use what works.

This has meant that when we found some useful Perl modules (like the one that implements "Benford's Law", Statistics::Benford), I had to learn how to use ActiveState's PDK.

When we decided to add interval maths to our project, I had to learn Ada and how to use both GNAT and ObjectAda.

When a high-speed string library was requested, I had to relearn assembler and get used to MASM32 and WinAsm.

When we wanted to have a COM DLL of libiconv (based on Delphi Inspiration's code), I got reacquainted with Delphi.

When we wanted to use Dr. Bill Poser's libuninum, I had to relearn C, and how to use Visual C++ 6's IDE.

We still prototype things in VB6 and VBScript, because they're good at it.

Maybe sometime down the line I'll end up doing stuff in Forth, or Eiffel, or D, or, heaven help me, Haskell (I don't have anything against the language per se, it's just a very different paradigm.)