Language interoperability is the capability of two different programming languages to natively interact as part of the same system and operate on the same kind of data structures.[1] There are many ways programming languages are interoperable with one another. HTML, CSS, and JavaScript are interoperable as they are used in tandem in webpages. Some object oriented languages are interoperable thanks to their shared hosting virtual machine (e.g. .NET CLI compliant languages in the Common Language Runtime and JVM compliant languages in the Java Virtual Machine).[2]
Object models are standardized models which allow objects to be represented in a language-agnostic way, such that the same objects may be used across programs and across languages. CORBA and the COM are the most popular object models.
A virtual machine (VM) is a specialised intermediate language that several different languages compile down to. Languages that use the same virtual machine can interoperate, as they will share a memory model and compiler and thus libraries from one language can be re-used for others on the same VM. VMs can incorporate type systems to ensure the correctness of participating languages and give languages a common ground for their type information. The use of an intermediate language during compilation or interpretation can provide more opportunities for optimisation.[1]
Foreign function interfaces (FFI) allow programs written in one language to call functions written in another language. There are often considerations that preclude simply treating foreign functions as functions written in the host language, such as differences in types and execution model. Foreign function interfaces enable building wrapper libraries that provide functionality from a library from another language in the host language, often in a style that is more idiomatic for the language. Most languages have FFIs to C, which is the "lingua franca" of programming today.
Object oriented languages attempt to pair containers of data with code, but how each language chooses how to do that may be slightly different. Those design decisions do not always map to other languages easily. For instance, classes using multiple inheritance from a language that permits it will not translate well to a language that does not permit multiple inheritance. A common approach to this issue is defining a subset of a language that is compatible with another language's features.[3] This approach does mean in order for the code using features outside the subset to interoperate it will need to wrap some of its interfaces into classes that can be understood by the subset.
Differences in how programming languages handle de-allocation of memory is another issue when trying create interoperability. Languages with automatic de-allocation will not interoperate well with those with manual de-allocation, and those with deterministic destruction will be incompatible with those with nondeterministic destruction. Based on the constraints of the language there are many different strategies for bridging the different behaviors. For example: C++ programs, which normally use manual de-allocation, could interoperate with a Java style garbage collector by changing de-allocation behavior to delete the object, but not reclaim the memory. This requires that each object will have to manually be de-allocated, in order for the garbage collector to release the memory safely.
Mutability becomes an issue when trying to create interoperability between pure functional and procedural languages. Languages like Haskell have no mutable types, whereas C++ does not provide such rigorous guarantees. Many functional types when bridged to object oriented languages can not guarantee that the underlying objects won't be modified.
Original source: https://en.wikipedia.org/wiki/Language interoperability.
Read more |