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?

Hereditament

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++.

Abracadabra

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.

Bendigo

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.

Acerbic

Exactly - most things I'm writing are in PHP, XML, XSLT, CSS, HTML and JS. Web development uses the best tool for the job in mulitple places all the time. – Hurlee

XSLT? It's like Greek to me. You forgot SQL on that list though. – Heartwhole

@Christopher Mahan: Yes! Exactly, as I said, "without even noticing" :) – Acerbic

Th eonly thing that differentiates the web stuff from ruby and C++ programming, is that in the web frameworks, the intrgration has already been implemented – Lanita

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.

Choleric

Answer 5

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,

Baxter

Answer 6

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?

Impaction

Answer 7

@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.

Euxenite

Answer 8

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.

Seduce

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.

Osorio

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.

Chamfron

Answer 11

It's quite common, but make sure you know why you're architecting it the way you do.

One example is in games programming. In many games, the performance-critical game engine is written in C, while things like level scripting are done in Python, Scheme, a home-grown language or whatever.

This means the performance geeks are working in a language they like and which gives them the low level control they need, while the level designers can work in a higher level language where they don't need to worry about managing memory and so forth.

Bendigo