Polyglot Programming: Is building applications with multiple languages a good practice?

Question

I am considering building an application that is a blend of a dynamic language (python or ruby) and compiled language and need some help getting convincing myself that this is a good idea.

My thought are that I can use a dynamic language to get a lot of code written quickly, and then dropping down to a compiled language like c/c++ to implement performance critical code.

I can see a lot of benefits of this approach:

1. Increased Productivity by primarily coding in the dynamic language
2. Availability of libraries from both languages

But there are also some downsides:

1. Maintaining a bridge between the two languages
2. Dependency on two languages and language/library bugs instead of one

What are the other pros/cons of this approach? Does anybody know about any resources and/or best practices around this?

Answer 1

I think your approach is very sensible. The way to address the downsides is to find out ahead of time how easy it is to interface the dynamic language with C or C++ before deciding whether or not to use it for your project.

Also, you need to think about whether or not you want your application to be cross-platform. A dynamic language is likely to be much less platform dependent, than a compiled one. That may be a factor in deciding which parts of the app should be done in C or C++.

Answer 2

I just re-read your question - your proposal to use C for performance critical code. Any dynamic language worth its salt has tools to let you access native code efficiently. So start by writing the whole thing in the dynamic language. You may find you don't need C after all.

But if you do, break out a profiler, carefully choose something to optimise, and go for it.

Answer 3

Ja, bien sur, mein freund. It is un'idea meravigliosa indeed. Boa sorte.

I'm joking of course. A web developer does that everyday without even noticing: Java, JSP, EL/OGNL, HTML, CSS, Javascript, ant, XML, XSLT...

I think polyglot programming is natural, powerful, efficient and more than else cool. It has to be used in the right way of course, to tap the maximum power of every language, and to not confuse the other people in your team.

Answer 4

Yes. Many programs are a mixture of a high-level language, like Python or Ruby, and a low-level language like C. You get the benefits of coding logic in a garbage-collected OO language and can still manually manage registers within tight inner loops.

Answer 5

@Zorkerman

I have experience with both Jython and JRuby... a lot more with JRuby.

I must say they are great platforms, and you get the huge benefit of dynamic languages, PLUS the rich 3rd and 1st party library support of Java, PLUS a highly platform independent base compiled language, PLUS garbage collection in both languages (it's important to understand memory management, but I'm of the camp that you are better off avoiding it unless you REALLY need it, such as if you are doing drivers or kernel level stuff, or stuff that need every ounce of performance you can muster).

I just want to give a quick anecdote. I recently was building a ruby script to index a Solr instance, and I needed to access a DB2 database (the source of our data to be indexed). Straight Ruby failed miserably... it has horrible DB2 support, which requires a full install of DB2 express edition... which still didn't work as advertised (I couldn't compile the Ruby drivers after I had finished installation). The solution was to just switch to JRuby and use JDBC from the Ruby side, using a couple easy to install jars (and much much MUCH smaller files than the DB2 install).

I would definitely highly advise considering JRuby or Jython instead of using C as your back end... I've found that algorithm and resource performance usually have a much much bigger impact on application performance than the language you pick, and the Java platform has so much to offer (and it has come a long way since the early days when people were decrying it as vastly slower than C/C++). Unless you are doing very heavy calculation intensive things that can't be refactored algorithmically, you most likely won't need to drop down to the compiled language, regardless of your pick.

---

PS The integration with Java in JRuby is very seamless (from the JRuby to Java side anyways), so maintaining a bridge is not an issue. Jython I think is the same, but again my experience with it is a lot less.

Answer 6

It's worth noting that Gambit Scheme and Chicken (and a few other implementations for that matter) run in an interpreted mode, and can then be compiled down to C.

Answer 7

You may find that you do not need to implement any performance critical stuff until a later time. So, I would fight hard against the entrance of one of these performance critical major changes until you are really sure you need to do it.

Otherwise just pick a root language, perl and ruby use c, so their incorporation is pretty simple. You could also run python (jython) or ruby (jrunby) on a Java VM, which would give you java as a backend. Though it might provide some other problems, as I am not familiar with developing against those versions of the respective languages.

not all performance problems will require you to drop down to a low level language though, so try and tackle it first in one langugae, before you quickly jump to another.

Good luck,

Answer 8

I'm in favor of using the best tool for the job. In the case of software engineering that means being polyglot. You would never expect a carpenter to use only a hammer, no matter what he/she were building. Why should it be different for us?

Answer 9

I think this is a good idea.

Since most (nearly all?) OSes are written in C or C++, every dynamic or interpreted language is at some level falling back to a compiled, optimized language for low level stuff.

Answer 10

Some folks argue that we programmers must master too many languages. They argue that adding a language is A Bad Thing.

The whole data access in SQL, presentation in HTML/CSS seems to be irreversible.

The XML thing is a bit tiresome: some people try to do everything in XML, as if XML has magical powers to make software better.

Also, there's a fair amount of redundancy because of the multiple languages. All of the inter-language bindings means that things get written twice, once in each language.