The Challenge of Cross-Language Interoperability

CowboyRobot writes "David Chisnall of the University of Cambridge describes how interfacing between languages is increasingly important. You can no longer expect a nontrivial application to be written in a single language. High-level languages typically call code written in lower-level languages as part of their standard libraries (for example, GUI rendering), but adding calls can be difficult. In particular, interfaces between two languages that are not C are often difficult to construct. Even relatively simple examples, such as bridging between C++ and Java, are not typically handled automatically and require a C interface. The problem of interfacing between languages is going to become increasingly important to compiler writers over the coming years."

Cross language - what .Net gets right

[cstec]

I don't even like .Net, but they won this round years ago.

Re:Java, all you need.

[Dahamma]

Clearly there is some sarcasm/irony, as "What do you need multiple languages for anyway?", "and this awesome applet I saw on someone's homepage once" is pretty clear (unless he's a moron).

But honestly the 80% of the rest of his points are actually true about Java - so either he doesn't really understand irony, he doesn't really understand Java, or he is just trying (rather successfully, IMO) to troll slashdot. I'm hoping that last case, in which I salute his efforts :)

Re:Java, C++

[serviscope_minor]

Java's JNI is poorly designed and makes no serious attempt to make interoperability easy because it is against Java's philosophy

I'm not an expert but I've done a bit of native language binding now and again. I didn't find JNI a massive barrel of laughs, but I didn't find it notably worse than other native bindings (e.g. CPython, ...). I was able to make calls in and out and throw java exceptions etc etc easily enough.

Can you be more specific without reference to higher level wrapper tools (e.g. Boost:Python) since those aren't really part of the languages.

C++'s runtime is deliberately completely implementation dependent because C++'s designers thought that might let implementors squeeze out a little bit of performance.

They made the right choice here. C++ compiles have come on an awfully long way since the beginning. One of the biggest parts of the runtime (exceptions) have gone from slow and painful to essentially zero cost if you never use them. That ould never have happened if the rnutime was heavily specified.

Besides, C++ is too portable for uch specification not to be quite harmful.

Sockets

[jhol13]

Use sockets. In majority of cases the performance is more than good enough, especially if designed properly, and you get network transparency "for free".
Sure there are cases where sockets are not appropriate, but IMHO they are far too seldom used.

Re:Cross language - what .Net gets right

[Dahamma]

.NET is already an extremely verbose platform that is many years ahead of its competition

Wha? Its "competition" for what, exactly? Windows apps? So, wait, you are telling me a Microsoft development platform is ahead of its competition for developing Windows apps? And how is that interesting?

Re:Cross language - what .Net gets right

[TheRaven64]

I talk a bit about .NET in TFA. It does some things right, but it still struggles with things like mutability. If you use F#, you get a language that is a lot like OCaml, and if you use it like OCaml, then it's fine. When you start trying to integrate with C#, then you find that they have different concepts of mutability. And you have to do it because the F# collection classes are much slower than their C# counterparts because the CLR lacks most of the optimisations that a typical OCaml implementation has to elide copies of immutable structures when your operation is implicitly destructive.

Re:Cross language - what .Net gets right

[Guy Harris]

Passing in registers is not a standard C parameter passing method

There's no such thing as "a standard C parameter passing method". Passing in registers is a perfectly legitimate C parameter passing method, used on several RISC architectures, such as SPARC [oracle.com], MIPS [sgi.com], 32-bit ARM [arm.com], 64-bit ARM [arm.com], and 64-bit {PowerPC/Power Architecture} [ibm.com] (and probably most other RISC architectures), as well as x86-64 [x86-64.org] and z/Architecture [redhat.com].

If there are more parameters than fit in the registers available for parameter passing, or if the parameters are in the variable-length portion of the argument list, they might be passed on the stack, and if the called function has no prototype in scope, the compiler might be forced to pass everything on the stack, but, in all other cases, if the ABI supports it, parameters can and will be passed on the stack.

Re:Cross language - what .Net gets right

[gbjbaanb]

don't - although the COM interop tooling for VB.NET is quite good, its all a massive performance penalty, and isn't quite as nice as its presented. The cross environment marshalling that's required (plus some pinning of data so the garbage collector becomes less efficient) means its there for convenience only. You wouldn't want to use it for heavy applications.

Microsoft wants you to rewrite in .net (well, then they did, now they want you to rewrite it all in WinRT).