Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Challenge of Cross-Language Interoperability

Soulskill posted about a year ago | from the porting-your-code-to-a-terrible-language dept.

Programming 286

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

Sorry! There are no comments related to the filter you selected.

Cross language - what .Net gets right (4, Insightful)

cstec (521534) | about a year ago | (#45592475)

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

Re:Cross language - what .Net gets right (2, Informative)

Darinbob (1142669) | about a year ago | (#45592591)

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 (3, Informative)

rnturn (11092) | about a year ago | (#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 (4, Informative)

cardpuncher (713057) | about a year ago | (#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.

Re:Cross language - what .Net gets right (1)

Darinbob (1142669) | about a year ago | (#45593027)

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.

Re:Cross language - what .Net gets right (2)

ebno-10db (1459097) | about a year ago | (#45593303)

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 (4, Informative)

TheRaven64 (641858) | about a year ago | (#45593143)

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.

Re:Cross language - what .Net gets right (1)

kthreadd (1558445) | about a year ago | (#45592603)

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 (4, Informative)

gigaherz (2653757) | about a year ago | (#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.

Re:Cross language - what .Net gets right (1)

kthreadd (1558445) | about a year ago | (#45592761)

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

Re:Cross language - what .Net gets right (1)

Dahamma (304068) | about a year ago | (#45592651)

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.

Re:Cross language - what .Net gets right (1)

gigaherz (2653757) | about a year ago | (#45592691)

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:Cross language - what .Net gets right (1)

Dahamma (304068) | about a year ago | (#45592781)

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*?

Re:Cross language - what .Net gets right (2, Interesting)

Pinhedd (1661735) | about a year ago | (#45592717)

.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:Cross language - what .Net gets right (4, Insightful)

Dahamma (304068) | about a year ago | (#45592803)

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

Anonymous Coward | about a year ago | (#45593063)

Yeah that's what we were shouting out for.

Win32 wasn't laborious enough, we wanted something more verbose that tried to use the kitchen sink approach to libraries, could call anything (as long as anything = a bloated Microsoft technology), suffers from DLL hell, and creates gargantuan applications that run out of memory quickly.

Re:Cross language - what .Net gets right (2)

WinstonWolfIT (1550079) | about a year ago | (#45592751)

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

Re:Cross language - what .Net gets right (0)

Anonymous Coward | about a year ago | (#45592907)

How well does it interface with Java? Oh.

Re:Cross language - what .Net gets right (1)

Adam Jorgensen (1302989) | about a year ago | (#45592909)

Seems to me like the cross-language compatibility thing is really won by the JVM given how active the JVM languages scene is...

Re:Cross language - what .Net gets right (1)

Big Hairy Ian (1155547) | about a year ago | (#45592931)

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

Re:Cross language - what .Net gets right (1)

Guy Harris (3803) | about a year ago | (#45593061)

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.

Re:Cross language - what .Net gets right (1)

Big Hairy Ian (1155547) | about a year ago | (#45593081)

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

Re:Cross language - what .Net gets right (3, Insightful)

Guy Harris (3803) | about a year ago | (#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.

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

TheRaven64 (641858) | about a year ago | (#45593083)

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.

this kind of comment system is dead (0)

Anonymous Coward | about a year ago | (#45592487)

every language but c and go suck

thats a fact

Re:this kind of comment system is dead (1)

narcc (412956) | about a year ago | (#45592519)

I don't even know why anyone would even bother with c++. If it's a good fit, just use c.

Torvalds is right about the language; even though he's right for the wrong reasons.

Re:this kind of comment system is dead (4, Informative)

stenvar (2789879) | about a year ago | (#45592597)

I don't even know why anyone would even bother with c++. If it's a good fit, just use c.

Because C++ lets people automate resource management and error handling, things that in C are manual and error prone. C++ also provides standards for abstraction, encapsulation, and substitutability, something that in C is not standardized and handled differently by every library. Despite C++'s many flaws and unnecessary complexity, it still is a better language than C for many projects.

Re:this kind of comment system is dead (1)

kthreadd (1558445) | about a year ago | (#45592605)

Better as long as you don't want to cross it with a different language I suppose.

Re:this kind of comment system is dead (1)

serviscope_minor (664417) | about a year ago | (#45592697)

Better as long as you don't want to cross it with a different language I suppose

Er, no.

C++ has C as almost a complete subset. Interfacing other languages is usually done in mostly the C subset. Except you get to wrap other-language structs in an RAII object so you never screw up resource management.

Re:this kind of comment system is dead (1)

kthreadd (1558445) | about a year ago | (#45592765)

So what you basically do is interfacing between C++ and C, and then between C and some other language.

Re:this kind of comment system is dead (0)

Anonymous Coward | about a year ago | (#45592955)

Calling C from C++ is easy, but what about the other way?

Have you tried instancing a C++ class from another language; from C instantiating a C++ class is a nightmare. You actually have to do this if you want to dynamically load a C++ library (plugins) even from within C++ (at least a few years ago you couldn't easily dynamically load a C++ library from C++, maybe it has been added to boost?).

Re:this kind of comment system is dead (3, Interesting)

ustolemyname (1301665) | about a year ago | (#45593321)

As someone who's done a fair bit of the reverse, and has recently needed to write C bindings for a few other languages (go, ruby), I thought this shouldn't be nearly so hard as you describe. Here's what I've come up with:

Example.cpp: Implements a class and C bindings for that class (The bindings could obviously be in a different file)
#include "ExampleCBindings.h"
#include
class Example {
public:
    Example(int v) { value = v; std::cout << "New Example(" << v << ")\n"; }
    ~Example() { std::cout << "Deleting Example(" << value << ")\n"; }
    int getValue() { return value; }
private:
    int value;
};

extern "C" {
    Example_class* newExample(int value) { return (Example_class*) new Example(value); }
    void deleteExample(Example_class* example) { delete (Example*) example; }
    int ExampleGetValue(Example_class* example) { return ((Example*) example).getValue(); };
}

ExampleCBindings.h: Public C bindings
#ifdef __cplusplus
extern "C" {
#endif
    typedef struct Example_t Example_class; // what I love most is that Example_t never exists ;)
    Example_class* newExample(int value);
    void deleteExample(Example_class* example);
    int ExampleGetValue(Example_class* example);
#ifdef __cplusplus
}
#endif

main.c: Simple C driver program that uses the api
#include "ExampleCBindings.h"
int main() {
    Example_class * ex1 = newExample(5);
    Example_class * ex2 = newExample(ExampleGetValue(ex1) + 2);
    deleteExample(ex1);
    deleteExample(ex2);
    return 0;
}

Limitations include:
* Does not support objects existing on the stack. You're in C, this is the norm for opaque data structures.
* Need to individually wrap every function. Would need to create separate wrappers for overloaded functions, or write a variadic function that doesn't enforce types (Sigh, neither language supports reflection)

However, if you only wish to implement public functions, writing a script that autogenerates a wrapper like this would be fairly easy (I've done similar for a mocking framework for C code - now that's actually painful (not the script, inserting stubbed functions into a binary)). A little googling came up with a more formal attempt here [dabeaz.com] .

Re:this kind of comment system is dead (1)

stenvar (2789879) | about a year ago | (#45593263)

C++ is a superset of C, and none of C++'s runtime features interfere with cross-language interoperability unless you actually use them and expose them. So, you're never worse off using C++, since you can always write your code the same way you would have done so in C and use C++ features only in a way that don't alter interfaces.

The only real disadvantage of C++ over C is the enormous complexity of C++. Functionally, it is superior in pretty much every way.

Re:this kind of comment system is dead (0)

Anonymous Coward | about a year ago | (#45592893)

Because C++ lets people automate resource management and error handling, things that in C are manual and error prone. C++ also provides standards for abstraction, encapsulation, and substitutability, something that in C is not standardized and handled differently by every library.

That is true, but C++ does it in a way that makes programming dangerous. In that way it is similar to C: you have to really watch out or you are going to mess your code up in subtle ways.

Despite C++'s many flaws and unnecessary complexity, it still is a better language than C for many projects.

Sure, but that is not really that meaningful.

Try Ada someday. It is a much better language.

Re:this kind of comment system is dead (0)

Anonymous Coward | about a year ago | (#45593001)

I use VHDL (Ada's little brother). It is a better language, if you like extreme-typing.

I am not sure how it is with Ada. But your VHDL program is proven (and then aggressively optimised) by the synthesizer (a compiler that produces a netlist to create electronics/FPGA to run your program), it does take a while for the synthesizer to be done.

Sadly VHDL has fallen behind its big sister because there are quite a few new Ada construct which would make my live a lot easier.

However the toolsets we hardware designers have to use cannot even keep up with VHDL language development. Most tools now finally work with VHDL1993, a few simulators can handle VHDL2000, almost no tool can handle VHDL2008. With tools I mean compilers. Yes, compilers haven't been updated to handle new language constructs since 1993.

As I am a software engineer as well, I am completely baffled by this. In the end this is because FPGA vendors don't want to disclose how the FPGA needs to be programmed.

At some point in the future (now that many FPGA patents have run out) there will be a vendor that will publish this and an open source toolchain can and will be developed. Then just like what happened to gcc, it becomes do-or-die for the current vendors.

From that point we can look beyond the old HDL languages and look in how to design higher level HDL languages. For example since a program needs to be proven anyway, it means that the synthesiser can infer all types all by itself. The language could become as clean in syntax as Python.

Re:this kind of comment system is dead (1)

ebno-10db (1459097) | about a year ago | (#45593403)

I use VHDL (Ada's little brother). It is a better language, if you like extreme-typing.

The typing stuff is a bit overdone, but I still much prefer it to Verilog. I'd rather spend time fighting the compiler than tracing down bugs in simulation that could have been caught earlier.

But your VHDL program is proven (and then aggressively optimised) by the synthesizer (a compiler that produces a netlist to create electronics/FPGA to run your program), it does take a while for the synthesizer to be done.

Synthesis is a step that simply doesn't exist in software. How does the synthesizer "prove" anything though, other than that you have a synthesizeable design?

Re: VHDL? this kind of comment system is dead (0)

Anonymous Coward | about a year ago | (#45593453)

If we mutate this thread to discuss hardware design languages, Verilog won the popularity contest. I really don't want to get involved with any project that dares mix VHDL and Verilog ... So mixing languages and HDL should be off the table :(

Re:this kind of comment system is dead (1)

ebno-10db (1459097) | about a year ago | (#45593377)

That is true, but C++ does it in a way that makes programming dangerous.

That's why the D language was developed [dlang.org] . It's something like C++, but done correctly with a clean sheet of paper. You can even understand the syntax! C++ programmers can easily learn it.

The question is whether D will ever catch on. It's not, or at least doesn't have the image, of a cool new language. The only chances I see for its success are 1) it'll be used on a lot of FOSS projects, so eventually enough people will want to darg it into their day jobs, and/or 2) some well known company starts using it internally. I'm not a big Facebook fan, but it would be a likely candidate, as Andrei Alexandrescu (C++ author and #2 guy on D) works there.

P.S. I also like Ada. At one time you had to be careful admitting that, but it's ok now because not many people know what you're talking about. It's dying though, and has been for many years. It's probably already a common topic at the Old Programmer's Home. D has a chance in part because it's newer (and more up-to-date).

Re:this kind of comment system is dead (0)

Anonymous Coward | about a year ago | (#45593435)

P.S. I also like Ada. At one time you had to be careful admitting that, but it's ok now because not many people know what you're talking about. It's dying though, and has been for many years.

I am not so sure about that. At least, it still is a quite viable platform. You can learn the language and do useful stuff with it, including GUI apps, and you can distribute them without problems. Many of the libs are quite up-to-date.

Anyway, why did you have to be careful admitting you liked Ada?

Re:this kind of comment system is dead (1)

serviscope_minor (664417) | about a year ago | (#45592723)

Torvalds is right about the language; even though he's right for the wrong reasons.

Bsically no.

He's a very good kernel engineer and wrote a very good DVCS. But he's full of shit when it comes to C++. Not a single point of his stands up to any sort of logical scrutiny.

I'd be quite surprised if anyone here will make such points either.

Re:this kind of comment system is dead (1)

narcc (412956) | about a year ago | (#45592787)

Not a single point of his stands up to any sort of logical scrutiny.

I guess you missed this part: "he's right for the wrong reasons."

I don't know why you're so defensive of the language. C++ hasn't exactly improved over the years.

Re:this kind of comment system is dead (0)

Anonymous Coward | about a year ago | (#45592853)

I guess you missed this part: "he's right for the wrong reasons."

I don't know why you're so defensive of the language. C++ hasn't exactly improved over the years.

What about C++11?

Re:this kind of comment system is dead (1)

kthreadd (1558445) | about a year ago | (#45592901)

Not to mention C++14.

Re:this kind of comment system is dead (1)

narcc (412956) | about a year ago | (#45593211)

What about C++11?

That's my point entirely. :)

Re:this kind of comment system is dead (2)

ebno-10db (1459097) | about a year ago | (#45593461)

I didn't sleep well. I'm tired and pissed off. Therefore a great distraction is to start a flame war!

He's a very good kernel engineer

Agreed.

and wrote a very good DVCS

Yes, bad user interfaces and mish-moshes of barely portable shell and C are the hallmarks of a good design. Mercurial is better, and has been chosen by most people/companies that have sat down and tried to make an objective comparison (e.g. Google, Fog Creek). Git is winning out mostly because it's what Linus, the ultimate cool kid, uses, and a lot of geeks still dream of sitting at the cool kids table.

But he's full of shit when it comes to C++. Not a single point of his stands up to any sort of logical scrutiny.

The one thing Linus does better than running the kernel project, is being an opinionated loudmouth. IIRC his hatred of C++ stem from an attempt in the ancient days of the kernel project to use it. At the time g++ seriously sucked. Small wonder it had problems. Or maybe Linus has a fear of objects because he was struck by one as a child, and doesn't like classes because he had to attend them (I said I didn't get much sleep).

Re:this kind of comment system is dead (1)

kthreadd (1558445) | about a year ago | (#45593493)

What's with classes and objects? You can use that with C, it's just not built into the language.

Re:this kind of comment system is dead (0)

Anonymous Coward | about a year ago | (#45593011)

Cross-platform GUI tookits. The C++ based ones tend to be nicer than GTK.

Context is an island somewhere: (0, Redundant)

Zanadou (1043400) | about a year ago | (#45592505)

It took me until the third sentence to work out that it's referring to programming languages.

decouple... SOA (0)

Anonymous Coward | about a year ago | (#45592523)

That said.... C rules!

Re:decouple... SOA (1)

ebno-10db (1459097) | about a year ago | (#45593469)

The joy of a least common denominator.

Java, all you need. (5, Funny)

magic maverick (2615475) | about a year ago | (#45592525)

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?

Re:Java, all you need. (0)

Anonymous Coward | about a year ago | (#45592573)

Gods damn, THIS!!!

Re:Java, all you need. (0)

Anonymous Coward | about a year ago | (#45592587)

Wait, upon rereading, I don't think that GP is actually being sarcastic. Can someone with a better online sarcasm detector please jump in here?

Re:Java, all you need. (4, Insightful)

Dahamma (304068) | about a year ago | (#45592677)

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, all you need. (0)

Anonymous Coward | about a year ago | (#45592725)

Ah, but that's the best kind of sarcasm, hidden well, only given out by a couple of clues (which are actually so damn obvious the next step would have been writing "" at the beginning). If you don't see that you are most likeke humor impaired, or american (don't know why, but many americans seem to be completely lacking the wits needed for subtle humor. Not all, but many)

Re:Java, all you need. (1)

Dahamma (304068) | about a year ago | (#45592823)

Does posting as an AC make you less of a prejudiced a-hole? No, I think not. Any possible points you may get for pointing out what has already been pointed out was lost when you decided you needed to stereotype 300 million people. But please come back when your balls drop.

Re:Java, all you need. (-1)

Anonymous Coward | about a year ago | (#45592973)

Seems like Americans are also whiny butthurt bitches. I almost wrote 'little bitches', but that would be quite ironic while referring to nation of morbidly obese.

Re:Java, all you need. (1)

ebno-10db (1459097) | about a year ago | (#45593489)

Wait, upon rereading, I don't think that GP is actually being sarcastic. Can someone with a better online sarcasm detector please jump in here?

Either you have a dry sense of humor, or this is Slashdot.

Re:Java, all you need. (0)

Anonymous Coward | about a year ago | (#45592575)

Is it ideal for number crunching? A lot of scientific software wants a nice front end but some heavy number crunching behind -- often as not written in Fortran.

Re:Java, all you need. (1)

texwtf (558874) | about a year ago | (#45592595)

And with its great collection of garbage you can be sure Java will utilize all of your memory proving it's the best.

Also with the great lengths of it's CLASSPATH you can be sure your PATH has a whole lot of CLASS! like 20k worth. Please, LD_LIBRARY_PATH? That's for luuuuzers. Winners know you should specify the whole location of every individual library used EVERY SINGLE TIME you call a "binary" so as not to get confused.

Re:Java, all you need. (0)

Anonymous Coward | about a year ago | (#45592621)

but in order for java to be cross platform, it has to abstract the underlying OS and of course the hardware.

and if hardware and/or OS is something you need to worry about (device drivers, embedded systems, Windows API, etc) then C is the ideal language of choice.

parent is obviously trolling...

Java, a horrible horrible language. (1)

Kjellander (163404) | about a year ago | (#45592647)

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 never needed for a real language, if you need an IDE, there is something wrong with your language.

Java does the opposite of trying to help you shoot yourself in the foot, by making the code bloated and spread out. More lines = more bugs, that is the simple fact.

Just-in-time does not make java "just as fast" automatically. I have 8 cores on my machine, and I can easily and safely make Erlang programs that max out all of them, and without any mutexes. The mutex model is just broken and as we move to more and more cores, you need languages that can easily and safely scale.

"Java unicode from the ground up", MY ASS! Why would you even make .toString() the default when converting from one type to the next. You always want .getBytes()!!!!

And stop smoking your crack for at least 5 seconds before lying to yourself about Fortune 500 companies not hiring anything but Java programmers. What do you think they coded Facebook chat in, for just one example? Not Java!

That should be enough fodder for the trolls.

Re: Java, a horrible horrible language. (1)

kthreadd (1558445) | about a year ago | (#45592663)

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.

Re:Java, a horrible horrible language. (0)

Anonymous Coward | about a year ago | (#45592795)

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

I was on your side initially, but after that statement I put you right next to the original troll in my mind...

Re:Java, a horrible horrible language. (1)

zwei2stein (782480) | about a year ago | (#45592927)

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 solved by single utility method call instead of about 15 lines of usage of raw engine.

Eventually you will need to start using raw engive anyway when you need advanced features - and then oneliners end everywhere.

Also, in my experience those line savers are inconsequential - "Hip" oneliners generally solve non-problems, they only make it look "Clever".

And "Clever" or "Hip" code is major pain to support once hype dries up.

Re:Java, a horrible horrible language. (0)

Anonymous Coward | about a year ago | (#45593187)

Agreed!

For example, try to explain why 'int' and 'Integer' are different?

Re:Java, a horrible horrible language. (0)

Anonymous Coward | about a year ago | (#45593319)

that's easy... int is a primitive data type... Integer is an object class representing an int (you know OOP and all...)

Re:Java, all you need. (0)

Anonymous Coward | about a year ago | (#45592695)

https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/

Re:Java, all you need. (0)

Anonymous Coward | about a year ago | (#45593025)

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.

Hi. God here. I totally agree and have decided to delete all C++ code from the planet. *pushes button* *Java VM disappears*

Java and C++ is not a simple example (0)

Anonymous Coward | about a year ago | (#45592529)

I hope JNI burns in hell

Java, C++ (4, Informative)

stenvar (2789879) | about a year ago | (#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++ (3, Insightful)

serviscope_minor (664417) | about a year ago | (#45592713)

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:Java, C++ (1)

Viol8 (599362) | about a year ago | (#45593417)

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.

Re:Java, C++ (1)

stenvar (2789879) | about a year ago | (#45593479)

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 implementation was the right choice, across the board? Let me bow before your awesome omniscience! Why didn't they come to you in the first place when designing the language?

Back in reality, there are some features that should have been left unspecified as they were, and there are others that probably should have been specified in the interest of interoperability, among other things because every major implementation implements it the same way anyway. It's understandable they made the choices they did back then, but the world has changed pretty significantly, and much of what we see in C++ is there for backwards compatibility, not because it's the best choice.

Re:Java, C++ (1)

abies (607076) | about a year ago | (#45593043)

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 and extra level of indirection start making sense...
JNI is sometimes hard/verbose not because they want to make C interfacing hard, but because they want to make Java JVM evolution possible. And yes, high-performance concurrent copying gc is a bigger priority for java usage than saving few minutes of one-time work when writing a JNI wrapper. Especially given Swig which automates almost everything.

Re:Java, C++ (1)

stenvar (2789879) | about a year ago | (#45593309)

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 direct call to a native function in a shared library should be enough. And unlike Java, where you pay at least two function call overheads (one from JNI to the C wrapper, a second from the C wrapper to the actual library function), such a scheme can compile and inline all the preparatory code using a JIT and then pay only for a single native function call into the shared library.

So, the Java JNI forces you to expend the effort to write native code wrappers for native libraries. Then you need to compile, package, and install these on every platform, making distribution and packaging a major headache. And to add insult to injury, the end result has higher overhead than if you could write the glue code in Java and just call the shared library directly.

Sort of (2)

EmperorOfCanada (1332175) | about a year ago | (#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.

Re:Sort of (0)

Anonymous Coward | about a year ago | (#45593215)

Nice theory!

SWIG is awesome (0)

Anonymous Coward | about a year ago | (#45592601)

We needed to interface OCaml and C++ in our project. SWIG was already being used to interface C and Java in other parts of the codebase, so we decided to give SWIG a try...with a few hiccups we managed to get it to work. Now that the infrastructure is in place adding new data structures to share is pretty easy.
I used to be a hardcore C programmer, but now I love OCaml and think it is wonderful for certain applications.
There is no getting away from having to mix multiple languages for a fair sized project I think.

THE ANSWER TO THIS PROBLEM IS THE CLOUD !! (0)

Anonymous Coward | about a year ago | (#45592609)

Simple. Instead of having to suffer through problems with the stack do very simple network calls to servers set aside to do just this, sort of like DNS today. Throw a buzzword on it like SDI Net, or something else cool sounding, and have ISPs maintain these SDI Net servers. Simple.

Interfacing 2 languages that are C *is* easy (1)

MikeTheGreat (34142) | about a year ago | (#45592641)

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

Re:Interfacing 2 languages that are C *is* easy (1)

serviscope_minor (664417) | about a year ago | (#45592681)

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

Re:Interfacing 2 languages that are C *is* easy (0)

Anonymous Coward | about a year ago | (#45592693)

Thing is, even that's not trivial. Some codebases aren't 64-bit clean and have to be compiled into a 32-bit mode, others were written for some fuck-off MS-DOS protected mode environment, and so forth.

Personally, I'm still holding out for some variant of CORBA IDL fundamentals to solve the problem in all directions. It's just that adequately transparent tooling doesn't seem likely to appear anytime soon: the Microsoft sphere is tied to COM, Free Software does IPC over DBus, and so forth -- and all of these require some form of the "write out a vtable-equivalent structure & duplicate threads in the out-of-process callee" dance in C.

(As for CORBA services, fuck that. In a very uncomfortable place.)

Re:Interfacing 2 languages that are C *is* easy (1)

elfprince13 (1521333) | about a year ago | (#45592791)

I just tried working with a codebase that had the same arrays storing both ints and pointers, and doing index arithmetic all over the place. The really horrifying thing was that it actually compiled 64bit, and just behaved differently.

Re:Interfacing 2 languages that are C *is* easy (2)

PolygamousRanchKid (1290638) | about a year ago | (#45592939)

I just tried working with a codebase that had the same arrays storing both ints and pointers, and doing index arithmetic all over the place. The really horrifying thing was that it actually compiled 64bit, and just behaved differently.

Well, as Bill Clinton so eloquently said:

"It depends on what the meaning of the word ints ints"

Re:Interfacing 2 languages that are C *is* easy (1)

gigaherz (2653757) | about a year ago | (#45592727)

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

MOST games/media apps are implemented this way... (0)

Dahamma (304068) | about a year ago | (#45592721)

Have you used Netflix, VUDU, Amazon, etc to watch movies (or, ok, World of Warcraft to play a game for this audience)? Then you have probably already seen this. Actually, even the WoW reference is unnecessary for anyone who understands game engines - almost all of them now use native cores + interpreted scripting engines.

Though I have to laugh at the article's choice of examples - holy crap, is CS academia really that far behind everyone else?

Re:MOST games/media apps are implemented this way. (2)

CommanderK (1078087) | about a year ago | (#45593073)

WoW uses Lua, which is actually known for having a very simple and easy to use interface with C code. I even found an example on the Wikipedia page: http://en.wikipedia.org/wiki/Lua_(programming_language)#C_API [wikipedia.org]

Premise is wrong (1)

YoungManKlaus (2773165) | about a year ago | (#45592745)

"You can no longer expect a nontrivial application to be written in a single language." ... that hugely depends on your definition of "nontrivial", but generally: yes, I can expect that and see no counter-indication for it.

The only exception is to have a kind of "core framework" which can be scripted and has an embedded interpreter (eg. python or similar), but that scripting language is then not a first-class-citizen on equal footing with the rest of the program, but a sort of "slave system" (does that make any sense?).

Sockets (4, Insightful)

jhol13 (1087781) | about a year ago | (#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.

Re:Sockets (1)

fozzy1015 (264592) | about a year ago | (#45592975)

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 (0)

Anonymous Coward | about a year ago | (#45593005)

SOAP is so much better than RPC. It's simple and allows access to objects! SIMPLE, I SAY!

Re:Sockets (0)

Anonymous Coward | about a year ago | (#45592985)

Yeah, right. End of story, eh?

Scarcity of single host applications (1)

Hypotensive (2836435) | about a year ago | (#45592821)

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 network connection without having to log in.

The popularity of the mobile app model is such that this trend is only going to increase. As such, the issue is not about binary runtime language compatibility frameworks like SWIG, but more about network protocols.

The real issue (0)

Anonymous Coward | about a year ago | (#45592879)

A programming language is just a syntax to express some concepts. The real question is: Why do we need a hundred different syntaxes to express the same concepts?

Python fairs pretty well (2)

pieleric (917714) | about a year ago | (#45592891)

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.

What is wrong with plain C? (0)

Anonymous Coward | about a year ago | (#45593137)

I really don't see the need to use any language other than C. It is simple, elegant, straightforward, portable and versatile, it allows you to do everything you need without too much cargo cult and there is an enormous number of tools available.

Use an Enterprise Bus (0)

Anonymous Coward | about a year ago | (#45593175)

This is what Enterprise Busses were invented for (DDS, 0MQ etc).

Leave windows behind please. (1)

upuv (1201447) | about a year ago | (#45593431)

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 it's architecture and require far to much skill and background to avoid.

Now compilers are NOT the issue. It's runtime binding that is the issue. Compilers do a great job. Runtime binding is where things really fall down. Again .NET. The more you can resolve binding issues prior to the runtime event the better. For example I'm sure a ton of people on /. can rant about the issue with RMI and the destruction it inflicts at runtime. I call RMI SUPER LATE BINDING. .NET is founded on the similar principles and it SUCKS.

Apps like SWIG allow you to create compile time bindings between libraries. Which though not perfect create far more robust interfaces between high level languages. Something you can actually test. Since interfaces from libs also tend to be stable. The are also robust.

Yes of course it is possible to build robust integrations which bind at run time. But the level of effort is ridiculous and is rarely justified in budgets of medium to small Enterprise.

The ultimate in cross-language interoperability (1)

Megane (129182) | about a year ago | (#45593465)

A quine chain in ~50 languages: https://github.com/mame/quine-relay [github.com]

Now that's what I call cross-language interoperability.

For bonus points, they're even in alphabetical order.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?