Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why aren't more applications written in multiple languages?

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.

like image 896
Kelly S. French Avatar asked Jul 15 '09 18:07

Kelly S. French


3 Answers

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.

like image 146
Jon Skeet Avatar answered Nov 15 '22 23:11

Jon Skeet


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.

like image 29
David Anderson Avatar answered Nov 15 '22 23:11

David Anderson


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.

like image 27
Frank Avatar answered Nov 16 '22 00:11

Frank