Well I know about .NET but its just for some predefined languages which are included in visual studio.But in the things I've read(they were not about this subject just mentioned it)the languages was not visual studio languages.I also searched in google but there were no useful result(maybe I couldn't find it so I request someone to do a professional google search about it).
Any way this is a really exciting concept for me.
Thanks for the info sharing on polyglot. It was really educating.
I think pywriter has posted a very interesting question. For the mentioned scenario, i wonder if inline programming exists in modern languages to solve this puzzle. Or this requires an inter-process communication through pipelining. Or better still, something else.
Most C/C++ compilers already have an inline assembly language at disposal. You can even make real-time assemblers and run the output within the program(loading up a pointer -- that's of the type pointer-function -- with the machine code and calling it), or make use of an available compiler like GCC and build code within the program like an IDE.
That's mostly about linking with libraries written in different languages (there's virtually no program that does not link with some library). As long as a dll conforms to the calling convention of the main program's language it can be linked and does not matter with which language it was originally written. If it does not conform, then some glue code can be written to make it so, have a look at http://www.swig.org
There's also embedding the interpreter of a scripting language in a compiled language. e.g. you can write a C program that executes Tcl code within. That's possible by linnking with the Tcl interpreter built as a dll and exposing its entry point as callable C function.
There is also the use of a scripting language to present the UI, trigger core routines written in C, C++, Prolog, FORTRAN, or whatever. Python has a quite accessible interface for doing that. The upsides to doing it this way:
You can prototype entirely in the scripting language: Quick and "easy", then gradually make the code more efficient by swapping out core routines written after you know where the hot spots are
Your users are mostly going to interact with (and thus want changes to) the UI. Having that be written in an "easy" language reduces the maintenance effort
By decoupling the UI from the core (which you have to do to make this work), you increase maintainability even for core routines. You can even rewrite them in an entirely different language, or offer options like "fast and approximate" versus "slow and right" that can be triggered at run time.
The downside to this is basically just one thing: The development effort is more complex the more different languages are involved. This one basic thing, of course, has a variety of particular symptoms.
Yes, it is possible to write programs in multiple languages, I do that semi-frequently. One of the easiest ways (at least in my opinion) is to compile the code into several object files, and then link them together.