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 ?
当然可以。通常，您会使用某种粘合层（例如管道、套接字、文件监视、共享内存、协议缓冲区）来允许不同的进程相互交谈/调用。
这当然不是不寻常的。
python 标准库的许多部分是用 C 编写的，许多流行的第三方库（例如 numpy）也有部分是用 C 编写的，您可以使用 ctypes 创建与自己的 C 库的绑定。Python 的默认 GUI 库 Tkinter 的一部分是用 Tcl/Tk 编写的。
Java 具有 Java 本机接口 (JNI)，可用于集成针对物理机而不是 Java 虚拟机编写的模块。Scala 可以使用为 JVM 编写的库（显然包括那些用 Java 编写的），它也可以使用 JNI。
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.
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.
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).
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