Making (desktop) software whose components are programmed in different languages?

Question

Can the different components of a desktop software be programmed in different languages ? For example, a software called MultiProg consists of components Comp1, Comp2, Comp3 etc. All components except 1,2,3 are in java and 1 is in C, 2 in Python, 3 in Scala etc. Is it possible to do that ? When does the need to do this arise ?

Is this commonly seen in the software industry ? How do we make the components communicate when they are written in different languages ?

Answer 1

It's certainly not unusual.

Many parts of python standard library is written in C, and many popular third party library such as numpy has parts of them written in C, and you can create binding to your own C library with ctypes. Part of Python's default GUI library Tkinter is written in Tcl/Tk.

Java has Java Native Interface (JNI) which can be used to integrate modules written to target the physical machine instead of the java virtual machine. Scala can use libraries written for the JVM (including those written in Java, obviously) and it can use JNI as well.

Most large softwares are written in multiple languages. Usually two languages are used, one is a fast, compiled language (usually C or C++) for performance critical sections and the other is a scripting language (for example Python, Lisp, Lua) to write the complex but not performance critical parts.

There are two requirements for any languages to be able to interact. One is they have to be able to share in-memory data in a mutually understood format, the second is they have to be able to call each other's functions using a common "calling convention". Native interface libraries solves those issues.

Answer 2

There's 2 ways this can be done.

The first way is to compile the different pieces (in different languages) into object files and link them. This only works for some languages and not others, and depends on the availability of suitable tools. For example, if one language does garbage collection you can't expect other languages to suddenly support it.

The other way is to build the application as separate processes that communicate/cooperate. This avoids the linking problem, but means that you've got separate processes (which can be "less clean") and serialisation/de-serialisation, etc.

Note: there is a third way, which is building an interpreter or something into the application to run scripting stuff. I'm not sure if this counts (it depends if you consider the scripts part of the application's code or part of the data the application uses at run-time).

Normally, nobody mixes languages without a good reason, because it's a pain in the neck for programmers. Most programmers know lots of languages but are only experts in a few, and the more languages you use the more chance there is that one or more programmers won't be able to comprehend one or more pieces of the application's source code.

Answer 3

If you're using Microsoft's .Net framework you can create components in any of the supported .Net languages that interoperate with no extra work on your part: for example your application could be written in C# and use DLLs from Visual Basic, C++/CLI, Boo, and so on (a list of languages here: ). .Net is available on windows and via Mono on OSX and Linux

Answer 4

It certainly can be done. Typically you'd use some sort of glue layer (e.g. pipes, sockets, file watching, shared memory, protocol buffers) to allow different processes to talk to/invoke one another.

Answer 5

Sure. Different components do different works. And they use IPC (Inter-processes communication) to exchange data. It is common on Linux. More details about IPC could be found here (http://en.wikipedia.org/wiki/Inter-process_communication).