I recently heard about the use of several different languages in a (big) project, I also read about famous services such as Twitter using Rails as frontend, mixed with some other languages, and Scala I think it was as backend.
Is this common practice? Who does that?
I'm sure there are disadvantages to this. I think that you will have problems with the different interpreters/compilers and seamlessly connecting the different languages. Is this true?
Why is this actually done? For performance?
I believe that in the case of Twitter it was performance related; Scala is quite a bit quicker than Ruby, and they use it to power their queue systems.
Aside from maintenance issues, using multiple languages together can help offset the downsides in each language. With Twitter, Ruby (on Rails) is great for running the frontend of their site, but it makes more sense to use a faster language to process the menial background tasks. Integration between the languages isn't difficult when it comes to queueing systems, as they can be entirely separate from the application itself and still perform their tasks correctly.
The question essentially comes down to Domain Specific Languages (DSLs). Sometimes one language is better suited for one part of the program, and another language for another program. The benefits (execution speed, or ease of development) often outweigh the drawbacks of mixing multiple languages.
- Is this common practice? Who does that?
Very common; I'd say nearly every large application is written in more than one language.
Consider the example of a game. The core engine is usually written in C or C++ for speed and low-level hardware access, but behaviour of objects and characters are scripted in a higher-level language like Lua.
- I'm sure there are disadvantages to this. I think that you will have problems with the different interpreters/compilers and seamlessly connecting the different languages. Is this true?
Yes, there is a certain amount of overhead to enable scripts to access the game objects and such.
- Why is this actually done? For performance?
Yes and no. If performance were not an issue, the entire game could be written in a scripting language. Some other reasons are:
Speed of development; imagine the overhead if all the little objects and characters in a game like World of Warcraft were written in C++. The program would have to be compiled and restarted for every little change.
Modularity; new objects can easily be downloaded and added/removed at runtime, and savvy users can even mod them.
Portability; the same scripts will run unmodified on different platforms.
I have several projects with mixed languages
In one case i have some F# mixed with c# because f# allowed me to code a problem easier (and was a challenge)
other cases would be mixing silverlight and .net in the same project - they use different CLR
in other cases i have vb.net and c# when companies had programmers that use multiple languages - most people i work with can't read c ... any code done in that would probably be not in the best interests of the employer.
The major disadvantage is that everyone who works on the code needs to know all the languages.
It's not soemthing i do often, but really its about the tools for the job imo.
I wouldn;t say it is done for performance usually ... although i have linked to c++ dll's when i need something to be done very veyr fast (graphics algorithms before i could do any cuda) ... the decisions surrounding performance are greater than computation time. Allt he usual overheads like sdcalability, ease of reading still come into it. Ie i think you can say its about performance as long as you dont limit performance to mean the speed o fthe programs execution
In a typical embedded application I write for the 8051, I have multiple languages involved:
I do this because I like to use the right tool for each job. I must use C and assembler for the tiny 8 bit micro. I use C as much as possible because I get more work done. I use Perl to handle complex build related tasks, because it is more productive than C and more powerful and portable than bash. I use GNU make as the foundation of my build because it is very well tailored for handling dependency relationships and makes it easy to create and maintain this metadata and apply it to my project build process--in other words: productivity.
The big disadvantage of this approach is the obvious one: understanding my app requires an engineer to understand C, assembly language, Perl and make.
Lots of projects are mixed language. One of the most commonly mixed-with languages is SQL, and it is showing a key feature of mixed-language projects: each language is focussing on the parts of the problem that it is good at, and compensating for the weaknesses of the other(s). In the case of SQL, it handles the relational database access, leaving other things (be it the GUI or the webservice or …) to other languages that are better at them. I'd go as far as to say that using a single language is almost like just using a hammer to make a house; yes, you need a hammer, but you need a bunch of other tools too.
I know of projects which use a mix of jQuery, Tcl, C, Fortran and SQL in the one project. (It's a web application, driven by a web server written in Tcl, with computational components in C and Fortran and a database accessed via SQL.)
Consider the average web project, and how many languages it involves:
HTML, CSS, JavaScript/JQuery, Java, SQL/HSQL.
When each language is far better suited to the domain than the languages you're already using, toss another language in.
I've also had data-heavy programs with a web front end written in Java, but a back end (to actually crunch numbers) written in C, hosted on different servers, and so on.
And I've gotta say, don't model off of Twitter. You're unlikely to have an idea that tons of people want that much, that has no built in profitability, that investors shower you at money for. They're also absolutely terrible at the fit and finish in places; if you ever put your Gmail password in, odds are it was transmitted in the clear, for example, and for at least two years, you could friend people without their permission through the text message interface. (Gah.)
Is this common practice? Why is this actually done? For performance?
Yes. People who do it are generally trying to reuse existing software (which you'll have noticed is written in multiple languages) or are trying to use several different languages, each one what it's good for.
Performance may sometimes be related; for example, I may want to use Lua for its rapid-prototyping abilities but connect it to a highly performant email parser written in C.
I think that you will have problems with the different interpreters/compilers and seamlessly connecting the different languages. Is this true?
Sometimes. The state of practice in multi-language is roughly that if a language will talk to anything other than itself, it will talk to C. So it's often possible to get things to work together through some sort of C-like interface.
Otherwise, the first problems typically surface either in memory management or in a VM layer, which we might consider examples of "managed code". It's very hard to get a Haskell program to exchange heap-allocated objects with a JVM, for example. A typically workaround is to treat these kinds of calls like remote procedure calls, just as if the programs were running in different processes or even on different machines. Such calls can involve substantial overhead, often making it prohibitively expensive for two different languages to share mutable objects, for example. If you don't have to mutate things, however, the overheads aren't so bad.
Summary: there are sound reasons to use different languages to solve different problems, and it would be surprising if a large software system did not use multiple languages (except maybe in single-language silos like Squeak Smalltalk, which simply don't talk to the rest of the world). There are certainly difficulties with interoperability, but the problem is an old one and workarounds are known.