Why aren't more applications written in multiple languages?

Question

Even 2 decades ago, it was possible to call code written in one language to call code written in another; in school we called assembly graphics routines from within Ada code for one class assignment. Notable exceptions are running compiled code from within scripts or executing a system command from within compiled code; but rarely do we write a library in C++ to use in our Java app. When Java first appeared and it was still slow, there was the option of writing the main app in Java and moving the bottleneck code into some C/C++ dll to be called using JNI.

So, after all these years, what keeps us from writing multi-language apps? The primary scenario I have in mind is when a language is considered a good choice if it weren't for some performance bottleneck (like in the earlly Java days) so it's written entirely in C instead using a mix of the two languages.

I'm interested in this from an architecture perspective as well as language-design. Do you have any good examples, success stories, or quotes?

[Edit] One of the best examples of this was the backlash against Java because of it's slow performance early on. Even though JIT compilers have addressed the issue, my question was always about writing software in a language that makes it easier to write, read, and maintain. If there is a bottleneck, write a routine in assembly or C just for the bottleneck. That way you should get the best of both worlds, at least theoretically.

Answer 1

"So, after all these years, what keeps us from writing multi-language apps?"

It might be perceived that there are too many gotchas with calling code in Language A from code in Language B. Byte alignment, endianness, order of parameters, etc. Covering all of the gotchas so that you can sleep at night takes time.

.NET tries to address these, but I'm not sure how well. That's another discussion.

Answer 2

Using multiple languages involves:

• A more diverse skillset, and not everyone can fix problems anywhere in the system
• Often some pain in terms of cross-language calls, depending on the languages involved. (Your example of JNI is good here - it's nasty IME. P/Invoke is a lot simpler.)
• Often more difficult debugging
• A more complicated build system (for instance, with Java you get portability - but then if you've got a native library to build and deploy as well, life gets harder...)

Yes, it can sometimes be worth it - but I wouldn't do it until I had a really good reason.

.NET and Java both make this a lot easier, of course - using different languages on one platform is a lot easier than interoperating between (say) managed and native code.

Answer 3

What makes you think this isn't happening?

My ASP.NET MVC applications have some C#, some VB.NET and some JavaScript. I could quite easily throw in some Python and F#, but haven't found the need to go that far.

Answer 4

The way I see it, there were two main reason for including multiple-langage support in an interpreter/compiler:

• to allow developers to write a function in assembly, in those rare cases when performance is critical to the app
• to ease the introduction to the new language to developers who may be familiar with some other language

The first one is rarely seen today, mostly due to the use of shared libraries (such as dlls) and increased abstraction (the abstraction layer between your code and the assembly underneath is pretty thick), while the second one is mostly a marketing thing, and marketing is usually not the main interest of the guy writing the language spec (.Net being the first exception coming to mind right now).

Answer 5

People write multi-language apps all the time. You mention compiled code called from script languages. That happens really often, e.g. C++ from Python, Perl, Lua or R. Or Java from Groovy. Not sure how often C++ is called from Java, but I'm sure it happens as well.

That's why swig is so popular.

Answer 6

A slightly different aspect:

In the 1980s there were few languages capable of a full range of functionality. A business application may be written in COBOL but if it needed complicated numerical routines these might be written in FORTRAN with bespoke Assembler used to manage the function calls from COBOL into FORTRAN. Nowadays there are a variety of choices for languages and associated libraries that can provide the whole functionality in one language.

Severe limitations on computer capacity (CPU, memory, disk, I/O speeds) also led to a need to use different languages for different parts of a program or system.

Answer 7

In my home projects, I call Fortran procedures from C, or C procedures from C++.

In my work code, we mix Java with a bit of C.

It still happens, but people try to avoid it, for good reasons.

Answer 8

UNIX has already solved this problem after a fashion. The UNIX style of writing small utilities that can be strung together to form a solution is one form of writing an app in multiple languages. Instead of defining the interface and/or mechanism for interaction between languages, e.g. JNI, the command-line or shell environment has become the defacto standard.

I wonder if exposure to UNIX, or lack thereof, is what has made this topic either not worth the effort or maddeningly complex respectively. That is, those with UNIX experience don't bother with JNI because they approach the design problem differently so that their application is more internally modular and cohesive; more conducive to turning into a component in a string of apps instead of a singular monolithic monstrosity.

Answer 9

The biggest problem that I see is because it requires everyone on the team to be very diverse (see Jon Skeet's answer). If you have a team of ten people and three know C# very well and some VB.NET, three know VB.NET very well and very little C#, and the other four know C++ very well, but are only okay on C# or VB.Net, can you imagine what kind of program they would write being multilanguage? It may turn out okay, but what if you lose a couple team members, time is of the essence, and say it was your C++ guys, now who is going to fix that code? Surely not the .NET guys who are not diverse in C++. This can cause a lot of problems.

The second reason I see why applications are mostly single-language today is because when you reach a high number of lines of code, it's very nice to be able to follow the same flow, patterns, and see the same type of code throughout the system. Your brain does not have to switch between languages to figure something out, because you're already "thinking C#" for example.

I have a friend who writes his user interfaces in VB.Net, and his backend code which he always stores in DLL's in C#. This is okay, VB.NET and C# work really well together, but say he needed to outsource it to someone to fix a segment of code where a bug was both in the VB.NET and C# code, well, he made to need to outsource two developers, one fluent in VB.NET, and the other in C#. This increases costs two-fold, as well as overhead when he could have just done it in one.

I however, completely agree about applications that may use C++ for performance critical sections. There are times, where simply .NET may not be a good choice for a performance critical segment of code. This kind of code mixing is absolutely okay.

In the long run, code mixing is not a bad thing. It can be good because it will help you as a developer become more diverse, change the way you think, and help you as a developer. But you must be prepared for more overhead, possibly costs, and maybe even some frustration along the way.

Maybe a good idea for you, (if you're looking for this type of answer) would be to choose the language per technology. I personally write all my web apps (asp.net etc) in VB.NET. It's fast to write, it's easy to read and easy to maintain. And for the web, that's exactly what you want. All my desktop applications however get pushed into C#, because it's a stronger language in some aspects, and offers a few things VB.NET does not. Really, here this is all personal preference, but you get the idea.

Answer 10

Even as a beginner programmer I've found myself needing to use a smattering of Assembly language in C code to speed stuff up. (This was for tracking a line with a camera feed using a fairly slow processor board for a class)

I would suggest that if someone is writing a piece in a certain language, than they are probably most comfortable with said language. There would need to be extremely compelling reasons to use a language that they are potentially less comfortable with.

In my understanding, many game developers will use assembly for critical math libraries.

Answer 11

I'm not sure what the reason is, but I imagine is has a lot to do with the "language-du-jour" mentality we started having at the end of the 90's. I'm about to embark on a maddening project that I want to write in C++, but I want to be available in many other languages. I'll probably use a combination of Swig and SpiderMonkey for this.

But a lot of it really comes down to no one creating a unified object/reuse interface short of .DLLs. COM was great on Windows. IDispatch made things available to anything that spoke IDispatch. It was great writing our components in C++ and using them from VBScript in ASP. But nothing like this has ever come about portably. Sure, attempts were made via CORBA and a half-dozen other half-baked and often poorly-received technologies - but they all have the data-marshalling problem, the invocation problem, performance issues, endian-ness issues. No one's really spent time trying to solve it, and now the industry is evolving towards SOAP to replace it for where performance doesn't count (and sticking to CORBA where it does).

Answer 12

Depending on how you look at this issue, there either are, or aren't, a lot of applications written in mulitple languages.

For example, consider a mash-up web app that uses several web services. Each web service can be written in a different language. So in a sense, such an application is written in many languages.

Alternatively, you can look at a "simple," non-mash-up, web app that might use:

• SQL for persistence,
• C#/Groovy/RoR/etc. for application logic,
• and JavaScript/CSS/(X)HTML for presentation.

There might even be an OR/M tool, or LINQ to SQL in the case of C#, for accessing the data store. Let's not forget a healthy sprinkling of regular expressions embedded at various levels of the code. These are all different languages. So in this sense, multiple languages are regularly used to build apps.

But I don't think that's what you have in mind. I think your intended scope is the "main body" of code produced by a single project team. You're wondering why a project doesn't write, say, one component in Java, another in Lisp, and a third in Erlang, and then link them all together as some unified deliverable.

Some answers have been proposed like the build/deploy is harder, or not everybody will be able to work in every part of the system, because of some lack of skill in particular languages. I'm not sold on those types of answers. I've seen nasty build/deploy scripts in projects written mainly in a single language. And in my experience, when almost any project gets to a certain size, especially if it was written by many minds, it becomes difficult for everybody to be well versed in every part of the system. Also, jumping from one language to another (given a sufficiently seasoned developer) really isn't as big of a hurdle as some make it out to be.

The problem is that we can't just plug together pieces of code like lego blocks. We'd like to, and in some cases, maybe we can sort-of, kind-of do that. The issue is mainly about the maturity of the specifications for the public component interfaces and the component dependencies. Again, I've seen this stuff get in the way of a "mostly one language" project. But when you jump language boundaries, the situation is more complicated.

Regardless, having the "right" language for the right problem is very valuable. If you really believe that you have three components that are best expressed in, say, Java, Lisp, and Erlang, then it is to your advantage to write those components in those languages. As long as you expect that the work required to link them together and maintain those links isn't greater than the value you get from writing in multiple languages.

So then it really comes down to reducing the costs of assembling the components. This is a slightly different notion than just saying "the build gets harder." With well defined public interfaces, proper information hiding, and relatively painless dependency discovery and resolution there's no reason why components of a single project can't be written in multiple languages.

Answer 13

One case is when libraries or other canned code come in a different language from the application. A lot of this stuff is written in C, and a whole lot of apps nowadays aren't written in C. Numerical stuff is often written in Fortran (in grad school, I had to interface a Fortran routine to a Common Lisp app).

When you've got important parts already written, it's a lot easier just to use additional languages than rewrite and verify other people's code.

Answer 14

I think a big part of the reason is because there are no compelling reasons to do so. If a language has a feature compelling enough to use (e.g., object orientation), then it's probably compelling enough to use for the whole project. BITD, it used to be that you'd re-write parts of your code in assembly language if it wasn't fast enough, or write adapters so you could call a FORTRAN statistics package from C. Nowadays, there isn't much pressure to do that. A lot of performance problems aren't fixable in code (e.g., network latency) and most companies that provide software components provide them in several "flavors" (e.g., Java jar files or .NET components). As others have mentioned, there's also a significant amount of inertia among many developers that tends to disincline them to learn a new language, especially if it's different. And, of course, if a language isn't different, then there probably isn't any compelling reason to learn it.

Answer 15

We write in multiple languages frequently. It depends on the task at hand. In a recent web application I coded the web framework in PHP, the client scrips in JavaScript, the back-end engine and PHP plug-ins in Delphi and the database in MS-SQL.

Currently I work in an environment where we perform rapid prototyping in Delphi and then send to production for coding in MS C#. The company also has a variety of other languages employed.

A few years ago I worked on a project that employed 8 different languages. It was a right mess, but it is still supported on a large scale.

So I really can't agree with the proposition by Kelly French that we are not using multiple languages. You only have to extend you application into a database or web service to find yourself mixing it up. There is not 1 language that will do it all. If there was, I'd be using it and attending it's church on Sundays.

Answer 16

My last 4 jobs have been apps that called:

• Java from C#, and C# from F#
• Java from Ruby
• Python from Tcl, C++ from Python, and C from Tcl
• Java from Python, and Java from Scheme

(And that's not even counting SQL, JS, OQL, etc.)

In my experience, the shift has been the opposite: more languages. Reasons for this include:

• standard VMs, like JVM and CLR, allow languages to unintentionally cooperate
• object systems on C, like GLib, provide similar functionality for natively-compiled languages
• computer systems are now big and fast enough that everybody uses a database with a query language (even SQLite is considered tiny now!)
• the most popular new platform, the web, requires you to use JS if you want responsive client-side interaction, and you're probably not using JS on the server
• the web also provides a natural way for integrating completely different programs in the same system, e.g., a Python program and a Ruby program, with the right CSS/JS/theming, could look identical and link to each other such that the user never even knew these were 2 separate programs

These are all paid projects, BTW. On my personal projects, I always end up using a single language. The simplicity outweighs the benefits of being able to pull a package and integrate it with my project quickly.

Answer 17

I've used a mix of C and Lua (or C++ and Lua) in recent projects. I feel it liberating to get two languages with different pros and cons to balance with. The Lua code gets mostly compiled (baked in) into the same exe, so the end result is just one binary.

Comments on difficulty of debugging this, and understanding all of it, are valid. It does keep the source line count low, though.

Apple's Objective-C does pretty much the same "amalgam" approach, but switching the mindset line by line. I find that difficulty. Lua and C(++) allows me to switch the mindset by source file.

Answer 18

Devs have been worried about performance, like optimizing virtual method calls in C++ or the byte-code runtime compiling of Java, since the assembler was invented. It's in their nature to question anything that isn't patently obvious.

Answer 19

Using multiple languages makes refactoring more difficult and expensive. Because actions like moving a method from one class to another are much more difficult when those classes are written in different languages.

Answer 20

I totally agree with the premise of this Question.

It is easier to learn multiple Domain Specific Languages than to try to learn to apply a General Purpose Language to a diverse set of domains.

Don't be fooled into thinking that using one General Purpose Language narrows the required skills and learning in any way. It's just that now you have to learn how to contort a single language into all sorts of shapes and learn a half-dozen frameworks to go with it.

We wrote a system that replaced 10,000 lines of general purpose Java code with 750 lines of code written in 2 DSLs and glued together with Java. We wrote it in 1/10 the time of the original system, including the DSL learning time.

Answer 21

I would say that many more applications than you think are written using several languages. Just an example:

• how many recent internet applications are written in C? almost none.
• how many IP stacks are written with another language than C? almost none.

Answer 22

This is mainly a management question. The answer is more rooted in economical rathen than technical. Simple put, it is more expensive. You can imagine all difficulties like harder to manage including debugging, refactoring, developer replacement, etc.

Answer 23

For many classes of applications, there simply is no need for "classic" multi-language projects (involving a high-level language and a low-level language), and the extra complexity cost is significant:

• your developers must understand all the languages involved
• your build system must support them
• portability will suffer
• bugs will be more obscure

OTOH, lots of modern applications already use many different languages, e.g. Java, JSP, XSLT, and Javascript might all be used in the same project.

Answer 24

I write in python which gets called from C, queries its DB using SQL, performs its I/O using HTTP, serves up documents that are described using TEI, transforms them using XSLT, renders its output on the client side using HTML and CSS, formats its non-document output in a special templating language, and adds functionality to its user interface using javascript.

You may have noticed, this is a fairly generic web application (except for the TEI). The techniques you are talking about are absurdly common these days. The motivation is not always to optimize speed-sensitive portions of the code, but the techniques are certainly out there.