1. The Challenge of Cross - Language Interoperability

2. Overview
The Problem
Challenges
The path forward
Questions

3. The Problem
software becoming more complex and hardware less homogeneous
Low-level languages:
programmers no longer have a single language they can use for all probable targets
High-level languages:
typically trade generality for the ability to represent a subset of algorithms efficiently
domain-specific languages are growing more prevalent
hardware less homogeneous = different instruction sets and capabilities come with different pieces of hardware; can’t use same methods on all
No low-level language has semantics that are close to a massively multithreaded GPU, for example
Programmers wanting to get the last bit of performance out of the available hardware no longer have a single language they can use for all probable targets.
A domain-specific language (DSL) is a computer language specialized to a particular application domain e.g. creating games, web (HTML) etc

4. The Problem
Non-trivial applications can no longer be expected to be written in a single language
=> interfacing between languages is going to become increasingly important
High-level languages typically call code written in lower-level languages as part of their standard libraries (for example, GUI rendering)
becoming more important for compiler writers

5. Challenges Object model differences Memory Models
single inheritance vs. multiple inheritance: Java | C++
Memory Models
automatic vs. manual deallocation
Exception interoperability
Mutability
functional languages vs. object-oriented languages
objects were described as “simple computers that communicate via message passing.” This definition leaves a lot of leeway for different languages to fill in the details:
Example: Should there be zero (for example, Go), one (for example, Java, JavaScript, Objective-C), or many (for example, C++) superclasses or prototypes for an object?
what happens if you want, for example, to expose a C++ object into Java? Solution: You could perhaps follow the .NET or Kaffe approach, and support direct interoperability with only a subset of C++ (Managed C++ or C++/CLI) that supports single inheritance only for classes that will be exposed on the Java side of the barrier.
Still have cognitive barrier: If you want to use a C++ framework directly, such as LLVM from Pragmatic Smalltalk or .NET, then you will need to write single inheritance classes that encapsulate the multiple-inheritance classes the library uses for most of its core types.
deterministic destruction: follows some rules, one situation always produces the same outcome; non-deterministic destruction: random order of destruction
For example, C++ and Objective-C both have similar notions of an exception, but what should a C++ catch lock that expects to catch a void* do when it encounters an Objective-C object pointer?
Even if you do catch the object pointer from C++, that does not mean you can do anything with it. By the time it is caught, you have lost all of the type information and have no way of determining if it is an Objective-C object.
Mutable object can be modified after it is created
This, combined with the deep copying problem, makes interfacing functional and object-oriented languages a difficult problem.
A deep copy copies all fields, and makes copies of dynamically allocated memory pointed to by the fields

6. The path forward
These problems can potentially be solved by compiler developers
More interesting alternative:
providing richer feature sets for high-level languages in hardware
starting with the compiler output for newer languages, rethink CPU design
Perhaps more interesting is the question of how many of these can be sunk down into the hardware.
The industry has spent the past 30 years building CPUs optimized for running languages such as C, because people who needed fast code used C (because people who designed processors optimized them for C, because...). Maybe the time has come to start exploring better built-in support for common operations in other languages.

7. Questions?