Language interoperability

Language interoperability is the capability of two different programming languages to natively interact as part of the same system.[1] Interoperability is advantageous because programming languages are optimized for specific tasks, and allowing them to communicate can create better systems.

There are many ways programming languages are interoperable with one another. HTML, CSS, and JavaScript are a form of language interoperability as they work together to render webpages. Some object oriented languages can do this thanks to the hosting virtual machine (e.g. .NET CLI compliant languages in the Common Language Runtime and JVM compliant languages in the Java Virtual Machine).[2] High-level programming languages are usually interoperable with some lower level languages, an example of which is Apple's Swift (programming language) and Objective-C.

Methods for interoperability

Object models

To facilitate interoperability between languages, one method is to use object models. CORBA and COM are the most popular object models. These standards provide a base set of rules for how object oriented languages would implement their data models to allow for a language-neutral way of implementing objects that can be used in environments different from the one in which they were created.

Virtual machines (VMs)
Different Languages compile into a shared CLI

A Virtual machine is software that emulates operating systems, and acts a buffer between the language and the hardware. This allows a program to run on any hardware or OS. An advantage to VMs can use these type systems to ensure the correctness of participating languages and gives languages a common ground for their type information. Another advantage is that languages designed for VMs compile into a low level intermediate language. The intermediate language then goes through its own compiler or interpreter which can do more types of optimization.[1]

Challenges

Object model differences

With 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 decision do not always map to another language easily. An example of this would be how different languages handle inheritance. A single class may have zero (Go), one (Java), or many (C++) superclasses. A common approach to this issue is defining a subset of a language that maps directly to the other, but can also fully understand the other language.[3] This approach does mean in order for the superset to communicate down it will need to wrap some of its interfaces into classes that can be understood by the subset.

Memory models

Differences in how programming languages handle deallocation of memory is another issue when trying create interoperability. Manual and automatic deallocation is not the only issue but if it has deterministic and nondeterministic destruction. Based on the constraints of the language there are many different strategies for bridging the different behaviors. C++ which uses manual deallocation could use a Java styled garbage collector by changing deallocation behavior to delete the object, but not reclaim the memory. This requires that each object will have to manually be deallocated, in order for the garbage collector to release the memory safely.

Mutability

Mutability becomes an issue when trying to create interoperability between functional and object oriented languages. Languages like Haskell have no mutable types, where in C++ there are some constructs to flag classes as immutable but lack support of determining if something is mutable or not. Many functional types when bridged to object oriented languages can not guarantee that the underlying objects won't be modified.

See also

References
  1. Malone, Todd (2014). "Interoperability in Programming Languages". CiteSeerX 10.1.1.684.337. Cite journal requires |journal= (help)
  2. "Cross-Language Interoperability". Microsoft Developer Network (msdn.microsoft.com).
  3. Chisnall, David (2013-10-01). "The Challenge of Cross-language Interoperability". Queue. 11 (10): 20–28. doi:10.1145/2542661.2543971. ISSN 1542-7730.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.