Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming

The Challenge of Cross-Language Interoperability 286

Posted by Soulskill from the porting-your-code-to-a-terrible-language dept.
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."
This discussion has been archived. No new comments can be posted.

The Challenge of Cross-Language Interoperability More

The Challenge of Cross-Language Interoperability

Comments Filter:

  • Cross language - what .Net gets right (Score:5, Insightful)

    by cstec ( 521534 ) on Wednesday December 04, 2013 @02:09AM (#45592475)
    I don't even like .Net, but they won this round years ago.

    • Re: (Score:3, Informative)

      by Darinbob ( 1142669 )

      This was one years before then, it used to be normal to be cross language. Ie, VMS was implemented in a variety of languages, Unix provided a common calling standard between languages, etc.

      • Re:Cross language - what .Net gets right (Score:4, Informative)

        by rnturn ( 11092 ) on Wednesday December 04, 2013 @03:15AM (#45592715)

        ``VMS was implemented in a variety of languages''

        (Hmm... I thought the lion's share (if not all) of VMS was written in BLISS.)

        You could definitely call, say, a VAX BASIC routine from a VAX FORTRAN program, VAX FORTRAN subroutines from VAX C programs, etc. And you didn't have to jump through a bunch of hoops to do it, either.

        • Re:Cross language - what .Net gets right (Score:5, Informative)

          by cardpuncher ( 713057 ) on Wednesday December 04, 2013 @04:59AM (#45593007)
          VMS was mostly written in BLISS, although there were chunks of Macro-32, particularly in the drivers. The big challenge in the Alpha port was effectively cross-compiling the Macro-32 code for Alpha hardware. Towards the end of Digital as an independent company, more development work was done in C.

          An early decision in the design of VAX/VMS was the definition of the "VAX Procedure Calling Standard" that dictated the instructions and mechanisms to be used for calling procedures, passing parameters and returning values, independent of language. All the compilers were expected to use this mechanism so that you could, for example, call a procedure written in VAX COBOL from VAX FORTRAN. This worked to a large extent, but it wasn't explicitly defined (and couldn't really be defined) whether compilers should use call-by-value, call-by-reference or call-by-descriptor for particular data types so additional semantic cruft was required to sort out the deails of parameter-passing. VAX C would sometimes pass a double-word argument in violation of the standard. The standard also had nothing to say about meta issues like run time initialisation, memory and thread usage, etc.

          That said, it was a revelation coming from an IBM world in which you'd sometimes have to write Assembler shims to patch up the calling conventions if you needed to get one language talking to another.

          • Outside the kernel, many of the VMS commands and utilities were written in a mish mash of languages, as if each programmer just chose what they wanted to use. BLISS and Fortran and Macro-32 all in the same program. There was also a data description language added to the mix to allow sharing data structures across languages.

            • many of the VMS commands and utilities were written in a mish mash of languages, as if each programmer just chose what they wanted to use

              If they chose languages that were better for the task at hand than others, that sounds like a good approach. VAX cross-language compatibility made it practical.

              BLISS and Fortran and Macro-32 all in the same program.

              Mixing BLISS and Macro-32 is hardly a kluge, but what utility mixed them with Fortran?

              There was also a data description language added to the mix to allow sharing data structures across languages.

              Another excellent idea, supporting cross-language operation.

              Between VMS and Alpha DEC manage to prove the old adage: if you build a better mousetrap, your company will go down the toilet. More recent companies learned from that, and avoid well thought out designs.

        • Re:Cross language - what .Net gets right (Score:5, Informative)

          by TheRaven64 ( 641858 ) on Wednesday December 04, 2013 @05:39AM (#45593143) Journal

          VMS managed to get the idea of the platform ABI specifying procedure call conventions right very early on. It had quite an easy job though. C, BASIC and Fortran are all structured programming languages with basically the same set of primitive types. None of them have (or, in the VMS days, had) classes, late binding, or real garbage collection. BASIC is kind-of GC'd, but it doesn't have pointers and so everything passed across the language barrier from BASIC was by value, so the GC didn't have to do anything clever.

          It's worth remembering that when VMS was introduced, other platforms were still having problems getting C and Pascal to play nicely together (Pascal pushing arguments onto the stack in the opposite order to C), so that's not to belittle the achievement of VMS, but it's a very different world now that we have Simula and Smalltalk families of object orientation, various branches of functional languages, languages like Go and Erlang with (very different) first-class parallelism, and so on.

    • Absolutely, but only as long as you cross languages that all compile to CIL which is a language in itself.

      • Re:Cross language - what .Net gets right (Score:5, Informative)

        by gigaherz ( 2653757 ) on Wednesday December 04, 2013 @03:03AM (#45592671)
        Not true. .NET assemblies are able to use both standard exports (C functions), and COM libraries (which can be coded in C, C++, VisualBasic 6, ...), and can also export COM interfaces to the .NET classes and through the use of assembly modification tools, also export C functions.

        • That actually sounds really cool. Must take a closer look at .NET now. :-)

          • Re:Cross language - what .Net gets right (Score:4, Insightful)

            by gbjbaanb ( 229885 ) on Wednesday December 04, 2013 @07:41AM (#45593623)

            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).

            • Re:Cross language - what .Net gets right (Score:4, Informative)

              by raddan ( 519638 ) * on Wednesday December 04, 2013 @01:38PM (#45598011)
              P/Invoke, the other interop mechanism alluded to by the poster, is substantially faster than COM interop. I spent a summer at Microsoft Research investigating ways to make interop for .NET faster. There's maybe 20 or so cycles of overhead for P/Invoke, which is practically free from a performance standpoint. In addition to having its own [reference-counting] garbage collector, COM has extensive automatic-marshaling capabilities. These things make interop easy, but they add substantial overhead compared to P/Invoke. On the other hand, P/Invoke is somewhat painful to use, particularly if you want to avoid marshaling overheads and play nice with .NET's [tracing] garbage collector and managed type system. P/Invoke will often happily accept your ginned-up type signatures and then fail at runtime. Ouch.

              Coming from the Java world, I was totally blown away by what .NET can do. I can't speak for Microsoft myself, but I would be very surprised if .NET was not going to stick around for a long time. With the exception of perhaps Haskell, the .NET runtime is probably the most advanced managed runtime available to ordinary programmers (i.e., non-researchers). And, with some small exceptions (BigInteger performance... GRRR!), Mono is a close second. What the Scala compiler is capable of squeezing out of the poor, little JVM is astonishing, but Scala's performance is often bad in surprising ways, largely due to workarounds for shortcomings in the JVM's type system.

            • 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.

              That isn't really true. Most of Microsoft's own "heavy applications" use it, heavily in fact. Both Office and Visual Studio use it a lot, especially the latter.

              Yes, it's slower than .NET-to-.NET, much less native-to-native. But any bridge is going to introduce overhead, when either side speaks a different language, utilizes different data structures etc. In that sense, P/Invoke is actually pretty slim, because so long as you use "blittable types", i.e. primitives and structs thereof - basically things that

    • Re: (Score:2)

      by Dahamma ( 304068 )

      If Microsoft "won" that round, why have they almost completely abandoned it in recent years?

      If you have tried writing a Metro app with any reasonably proprietary support for media capabilities, it's a convoluted nightmare of "unsupported APIs", media pipelines, etc just to do anything interesting. And that's just Windows 8 on a PC! As much as they pretend Xbox One is "the same" as Windows 8, it's not, and requires a whole new level of bending over backwards to accomplish anything.

      • Modern apps (the new name of metro) use WinRT, which is NOT a complete CLI environment. It has a subset of the CLR classes, and then adds some proprietary extensions to it. It's designed to ease the walled garden lock-in, not to improve the programming experience.

        If .NET has been neglected somewhat, it's simply because it's not profitable enough to justify any more spending on the platform.

        • Re: (Score:2)

          by Dahamma ( 304068 )

          Yes, that's exactly my point (and I'm going to continue to say "Metro" with impunity - do you work for Microsoft or just a party-liner? ;) - WinRT is not .Net, MS has embraced WinRT (or even a *subset* of WinRT on non-PC platforms), ie. WHAT in effect have they "won" with this platform in the *long run*?

        • WinRT, which is NOT a complete CLI environment

          That's sort of a logical consequence of the fact that perhaps with the exception of the metadata format, WinRT has nothing to do at all with CLI. Therefore, it's not even a partial CLI environment, much less a complete one!

      • Re: (Score:3, Interesting)

        by Pinhedd ( 1661735 )

        .NET is already an extremely verbose platform that is many years ahead of its competition. If it seems like they've neglected it a bit that may be because there's currently either no motivation to add new features to it, or there's currently not enough features worth adding to it that would justify an incremental release and all of the accompanying documentation. I'd rather that they take a step back, let it mature a bit, and clean things up a bit if necessary.

      • Re: (Score:2)

        by Dunbal ( 464142 ) *
        "Extinguish"

      • If Microsoft "won" that round, why have they almost completely abandoned it in recent years?

        The .NET Framework was last updated 47 days ago (as of this post). That's so far from 'abandoned', I wonder if you're just trolling (which you almost certainly are).

    • .NET backend + javascript front end, job done. It's mature, feature complete almost to exhaustion, and turns modern-day developers to focus on business requirements and integration.

      • It's mature, feature complete almost to exhaustion, and turns modern-day developers to focus on business requirements and integration.

        You could say the same thing about Franz Allegro CL, or pretty much any established environment for that matter.

    • Personally I always preferred calling C functions from machine code it's easy just push your parameters or pointers to your parameters onto the stack and call the address of the function. Then again I initially read the summary and thought he was on about supporting French & German :)

      • Personally I always preferred calling C functions from machine code it's easy just push your parameters or pointers to your parameters onto the stack

        ...except for the ones you pass in registers.

        • Passing in registers is not a standard C parameter passing method you're probably talking to pascal :)

          • Re:Cross language - what .Net gets right (Score:4, Insightful)

            by Guy Harris ( 3803 ) <guy@alum.mit.edu> on Wednesday December 04, 2013 @05:45AM (#45593173)

            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.

          • Passing in registers is not a standard C parameter passing method

            So, when are you going to finally upgrade to AMD64? ;-)

    • Re:Cross language - what .Net gets right (Score:5, Insightful)

      by TheRaven64 ( 641858 ) on Wednesday December 04, 2013 @05:25AM (#45593083) Journal
      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.

    • .net did not get it right - they basically said "there is 1 language, the CLR and it runs in its own little sandbox. We might add some crappy hooks to let others play with us, but they'll be terribly inefficient and difficult to use".

      Its the same with Java - the environment is almost deliberately designed to be "java only".

      If .net had built its tooling to run natively instead of in the managed sandbox then I think they could have done better with the interoperability. As it is, they really want you to becom

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

      I think you have misspelled "Scheme".

  • Java, all you need. (Score:5, Funny)

    by magic maverick ( 2615475 ) on Wednesday December 04, 2013 @02:23AM (#45592525) Homepage Journal

    What do you need multiple languages for anyway? Java does everything you could want. Java is a powerful, object-orientated, cross-platform language, with fully developed GUIs, such as Swing.

    To demonstrate the superiority of Java, I can point to such leaders in their field as Eclipse, Minecraft, and this awesome applet I saw on someone's homepage once.

    Anyone still using ancient and difficult to use languages such as C++ (let alone C!) are obviously crazy, and probably should be committed for their own good before they go on spree of shooting (not just themselves, but) other people in the foot. Java makes it almost impossible to shoot yourself, let alone others, in the foot.

    Moreover, because Java is licensed under the GNU GPL, you can leverage the wisdom of crowds, and the powerful "many eyes make bugs shallow" concept to be confident that Java is the best.

    And with just-in-time, Java is as fast as any other language, so you don't have to worry about the speed of execution. Instead, you can focus on developer time, and Java's just faster in that regard.

    With built-in, from the ground up, support for Unicode, Java is there for the future, and is ready to be used across the multiverse (as soon as those aliens get their scripts into Unicode). Beat that C, with your lack of a string type.

    And if you aren't convinced, tell me why do so many top enterprises use this language? You don't see ads from Fortune 500 companies looking for Ruby "developers" do you?

    • I'm sitting right now and coding an interface between Java and Erlang using JInterface, and the actual JInterface part is pretty good. It makes Java act as an Erlang node. But Java is just a horrible, horrible language.

      Everything on the Java side gets so bloated it is just silly. What would take one line on the Erlang side can easily take 20 lines on the Java side.

      I know you are just trolling, but...

      Swing is the most horrible toolkit I've ever tried to use. Even monkeys can make a better one.

      Eclipse is neve

      • At least the language problems can be solved by using another language that compiles to Java byte code. Scala for example, which should be somewhat better in term of bloat size.

      • IDE:

        Eventually, projects get complex and you do need ide not to tame language but to keep being productive without having to cross check documentation of different modules. But have fun managing to write ~150 entities relating project in plain text.

        Verbosity:

        1-line-in-20 is usually just lack of knowledge of how to do something right in one language paired abuse of highly specialized construct in another.

        I have seen people complain how terrible i.e. (regxex, xml, etc.) is in java, but their problem was solve

        • Re: (Score:2)

          by dargaud ( 518470 )
          Like a former boss of mine said: "When you think you have a clever programming trick... forget it !"

      • Re: (Score:2)

        by delt0r ( 999393 )

        Eclipse is never needed for a real language, if you need an IDE, there is something wrong with your language.

        Oh your one of those people.....

  • Java, C++ (Score:5, Informative)

    by stenvar ( 2789879 ) on Wednesday December 04, 2013 @02:35AM (#45592577)

    The fault here lies specifically with Java and C++. Java's JNI is poorly designed and makes no serious attempt to make interoperability easy because it is against Java's philosophy. C++'s runtime is deliberately completely implementation dependent because C++'s designers thought that might let implementors squeeze out a little bit of performance.

    Nevertheless, tools like Swig make even Java/C++ interoperation fairly easy, and many other languages try to accommodate C++ well (cf. Boost::Python).

    • Re:Java, C++ (Score:4, Insightful)

      by serviscope_minor ( 664417 ) on Wednesday December 04, 2013 @03:14AM (#45592713) Journal

      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.

      • Re: (Score:2)

        by Viol8 ( 599362 )

        It would have been nice however if the C++ committee had specified a standard mangled format for class methods in binaries.

        eg:

        class foo
        {
        void myfunc() { }
        };

        will ALWAYS have the symbol name something like "__cpp_foo_myfunc" in the object file with the first parameter being a pointer to an object - ie "this". Instead of different compilers mangling the name in their own way. That way you could dlopen() a c++ binary with ease and use the methods directly.

      • 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, ...).

        In Python and other HLLs, you can do all the C binding in the HLL itself, allowing you to call most shared libraries directly. In Java, you always have an extra function call overhead and you need to distribute an extra native code library.

        They made the right choice here

        Really? For every single feature in the language that's unspecified, leaving it unspecified and up to the impleme

        • In Python and other HLLs, you can do all the C binding in the HLL itself,

          If by that you mean something like CTypes in Python, the same existst in Java too: JNA.

          you need to distribute an extra native code library.

          Yes, but that's not always a big problem. I've only ever used JNI to interface to a big blob of C++ code that I wrote in C++ for speed (and because it's a nicer language for this sort of thing than Java). In that case, the binary has to be distributed no matter what the host language.

          Really? For ev

        • Re: (Score:2)

          by dkf ( 304284 )

          In Python and other HLLs, you can do all the C binding in the HLL itself, allowing you to call most shared libraries directly. In Java, you always have an extra function call overhead and you need to distribute an extra native code library.

          On the other hand, general function call overhead is higher in Python than in Java (for various good reasons!) so arguably what's actually happening is that you're just having to introduce the cost in Java that was there all along in a higher-level language.

          If you're really worried about the cost of calling, measure it and see whether it really matters.

      • One of the biggest parts of the runtime (exceptions) have gone from slow and painful to essentially zero cost if you never use them.

        I've heard that before and am seriously interested in 2 questions:

        1. What changed to make exceptions efficient? I know it's a a compiler issue, but if anyone is knowledgeable about the details or has a link, I'd be very interested.

        2. Any benchmarks, cites, whatever?

        #2 is not about skepticism, but being able to shove documentation under someone else's nose. I do a lot of "deeply" embedded stuff (no OS - RTOS or even bare metal, extremely low latency requirements, extremely performance critical in some areas)

        • One of the biggest parts of the runtime (exceptions) have gone from slow and painful to essentially zero cost if you never use them.

          I've heard that before and am seriously interested in 2 questions:

          1. What changed to make exceptions efficient? I know it's a a compiler issue, but if anyone is knowledgeable about the details or has a link, I'd be very interested.

          2. Any benchmarks, cites, whatever?

          #2 is not about skepticism, but being able to shove documentation under someone else's nose. I do a lot of "deeply" embedded stuff (no OS - RTOS or even bare metal, extremely low latency requirements, extremely performance critical in some areas) and the standard rule for years has been to turn off exceptions. Many compilers for embedded work even do that by default. I'd love to be able to change that, since exceptions make error handling so much easier.

          Just thought of something else: even if modern compilers have improved, it's far from a guarantee that ones for embedded use have. At least gcc should though, and that's used for some embedded work.

          Your Mileage May Vary. I recommend doing performance tests. It doesn't matter how any other system handles exceptions. Only the ones that you use yourself.

        • 1. What changed to make exceptions efficient? I know it's a a compiler issue, but if anyone is knowledgeable about the details or has a link, I'd be very interested.

          I believe the old way was to add stuff to the stack frame in order to track things. This obviously added overhead. The new way was to build a lookup system that takes the PC and uses that to jump into the unwind code. I think the lookup of the PC is quite slow, but it does not add any cost on the hot path.

          In terms of benchmarks, try running the

          • I believe the old way was to add stuff to the stack frame in order to track things. This obviously added overhead. The new way was to build a lookup system that takes the PC and uses that to jump into the unwind code. I think the lookup of the PC is quite slow, but it does not add any cost on the hot path.

            Nice approach. Who cares how long it takes once you've thrown an exception?

            In terms of embedded code... yeah dunno.

            Ideally what I'd like is to have the lowest, most speed critical code, not throw exceptions or incur any overhead due to their existence. I know that a function that doesn't throw any exceptions itself still has to have some provision for dealing with exceptions, but suppose you could guarantee that function foo() throws no exceptions and that none of the functions it calls do. Would a nothrow decl for foo(), and no catch statement i

    • Re: (Score:2)

      by abies ( 607076 )

      I would be very careful with claims about poor design of JNI. There are multiple aspects which are non-obvious to person who 'just want to call that single native call without hassle'.
      Example - think about implementing GC which is concurrent and copying. You want to perform it while some piece of code is inside JNI call (it might stay there forever, for example waiting for I/O). That bit of JNI was passed references to few of your java objects. Suddenly, a lot of magic around JNI local and global references

      • I am careful about such claims, having used native code interfaces since long before JNI was even conceived. Dealing with resource management and relocating garbage collection isn't rocket science, and JNI does it poorly.

        Part of the problem is that Java refuses to provide unsafe primitives in the Java language itself, for no good reason. That means that all the heavy lifting needs to be done in C. Most native code calling shouldn't require writing any wrappers; a little preparation in the HLL followed by a

        • Java refuses to provide unsafe primitives in the Java language itself

          They're trying to save you from yourself, or from the most inept programmer you have. Sorry folks, there is no such thing as an idiot proof language. A simple and effective approach, which other languages use, is to have anything that's unsafe include "unsafe" in their name. Then you can find where it's used with a simple text search (or is that too simple for a modern IDE?).

        • Part of the problem is that Java refuses to provide unsafe primitives in the Java language itself, for no good reason.

          There's a reason. Java wasn't designed to be unsafe. It exerts a lot of effort to avoid being unsafe, which is why things like buffer overflows are not routine exploits in Java code. It also takes the "write once/run anywhere" concept very, very seriously. Once you reach the JNI level, of course, all bets are off, but again, Java is primarily self-contained.

          If these features are an impediment, Java isn't the best platform to be using.

  • Sort of (Score:3)

    by EmperorOfCanada ( 1332175 ) on Wednesday December 04, 2013 @02:37AM (#45592585)
    Theoretically in a large organization with a huge and demanding application allowing developers to be able to interface with some sort of API with whatever language they choose may seem like a very flexible solution. I would be very worried that after a few years your code base would not only include a broad spectrum of languages but even potentially a broad spectrum of versions of those languages.

    I suspect that you would find yourself having to learn Haskell for one emergency and Erlang for the next.

    Where a multi language compatible API would be great though is when you start to migrate your system from one language to another. If you could do it piece by piece deploying each small well tested piece before moving on to the next I would suspect that many a disaster would be avoided.

  • In particular, interfaces between two languages that are not C are often difficult to construct

    (Yes, I know what they mean. I think they meant to write "In particular, interfaces between two languages (when neither is C) are often difficult to construct".
    Still, it amuses me to think about making an interface from C... to C :)

    • Interfacing 2 languages that are C *is* easy

      You have a different definition of easy than I do.

      Interfacing from X to C is usually *possible*.

    • Well there are such things as different kinds of C. You could have to interface cpu-C with gpu-C (like cuda).

  • Sockets (Score:5, Insightful)

    by jhol13 ( 1087781 ) on Wednesday December 04, 2013 @03:38AM (#45592785)

    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.

    • 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.

      At that point one might as well go with RPC.

    • Re:Sockets (Score:4, Informative)

      by Viol8 ( 599362 ) on Wednesday December 04, 2013 @07:15AM (#45593523) Homepage

      We're talking about loading libraries , not inter process communication.

      But sure, instead of loading libs written in one language into another language you could just have N processes all written in different languages and communicate that way, but it would be at least an order of magnitude (probably 2) slower than directly linking in a library to your running process.

  • One facet of this is that increasingly, any application of any great interest runs over the network, often using HTTP, so its UI is coded in JavaScript or somesuch and the back end can be any motley arrangement you like that happens to work.

    Even traditionally single-host applications like word processors nowadays involve mechanisms for installing software updates and online dictionaries or cloud-based functionality. As for games, you can't even launch most single-player games that should have no need of a n

  • Python fairs pretty well (Score:3)

    by pieleric ( 917714 ) on Wednesday December 04, 2013 @04:17AM (#45592891) Homepage

    On this aspect, Python does handle interoperability pretty well (at least with C and C++). It might just have a little bit too many options:
      * ctypes: connect to any C library directly (you just have to not do any mistake in parameters, as there is not check)
      * Python C extention: write a wrapper in C.
      * SWIG: "automatically" generates the wrapper, based on some .h-like file
      * cython: write C code using python syntax

    Personally, I just use ctypes or cython, and it's quite easy to interpolate with any software library I need.

  • Seriously,

    This is the plight of windows ecosystems. Linux/Unix has had abilities in this regard for many many years. It's stable it's rock solid and it performs.

    Java is a bit of a nightmare for performance. But a ton of Enterprise is written in Java. Depending on your role you would argue the same thing for python, perl ruby etc. The later languages tend to perform better when calling native libs and vice versa. .NET is an abomination of performance an security disasters. These issues are backed into

    • Java is a bit of a nightmare for performance.

      Citation needed.

      Modern JVMs often out-perform even assembly language due to their ability to analyse and tune for the actual operating environment. Java routinely out-performs C - which like assembly produces static code that cannot automatically tune itself at run time. We're no longer doing interpreters with the old 10-to-1 performance differential that such environments were known for.

      True, a small, trivial Java program will perform horribly relative to an equivalent non-VM language. The VM takes a lot

      • Re: (Score:2)

        by upuv ( 1201447 )

        Of course a JVM out performs assembly. Think about how the assembly was written. True assembly is written by hand. And it's painfully difficult to write.

        Java doesn't outperform optimized C or C++ in reality. Java can't even touch languages like perl for manipulating textual data. But you can certainly produce functional code faster in Java than most languages. It really is a great language for getting stuff to market quickly.

        My job is performance engineering. This is what I live and breath. Java is a

        • When all's said and done, when you put power tools in the hands of the incompetent, you amplify their incompetence.

          Most of the examples you listed weren't faults of Java, they're faults of the architects and people like that commit similar atrocities whether in Java, C, or VB. IBM mainframes were performing address-space hopscotch on CICS before Java was even born.

          As for WebSphere, IBM isn't as ubiquitous as they used to be. Every few years I have to work with it. The rest of the time I have better tools at

  • Been there, doing that (Score:3)

    by lwriemen ( 763666 ) on Wednesday December 04, 2013 @08:31AM (#45593953)

    Shlaer-Mellor / Executable UML have been offering this type of language independence for over 20 years. The method works from business to embedded software. All that's required is model compiler support for the target language, which can be bought off the shelf or made in-house. Currently model compilers exist for C, C++, Java, Ada, System C, and I'm sure there's more that I haven't encountered.

Slashdot Top Deals

Garbage In -- Gospel Out.

Close