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

Comments

Cross language - what .Net gets right

[cstec]

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

Re:Cross language - what .Net gets right

[Darinbob]

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

[kthreadd]

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

[Dahamma]

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

[gigaherz]

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

[gigaherz]

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

[rnturn]

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

[Pinhedd]

.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

[WinstonWolfIT]

.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

[kthreadd]

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

Re:Cross language - what .Net gets right

[Dahamma]

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

[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

[Anonymous Coward]

How well does it interface with Java? Oh.

Re:Cross language - what .Net gets right

[Adam Jorgensen]

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

[Big Hairy Ian]

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

[cardpuncher]

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

[Darinbob]

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

[Guy Harris]

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

[Anonymous Coward]

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

[Big Hairy Ian]

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

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

[TheRaven64]

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

[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, MIPS, 32-bit ARM, 64-bit ARM, and 64-bit {PowerPC/Power Architecture} (and probably most other RISC architectures), as well as x86-64 and z/Architecture.

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

[ebno-10db]

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

[Dunbal]

"Extinguish"

Re:Cross language - what .Net gets right

[RaceProUK]

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

Re:Cross language - what .Net gets right

[gbjbaanb]

.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 become a .net-only shop. (even things like WCF have the crappy options for interop, so if you want to interact with a .NET WCF service, you either have to go with shitty SOAP, as the fast and efficient socket option is .NET only).

I know you meant lots of languages can be run in .NET, like VB.NET or C# or F# or IronPython, but really they are just syntactic sugar on top of the underlying bytecode. All that is different is the words used to code up your program, some have curly braces, some have BEGIN/END.. the difference is superficial.

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

Re: Cross language - what .Net gets right

[Anonymous Coward]

Any language + javascript front end, job done... What was the point?

Re:Cross language - what .Net gets right

[K. S. Kyosuke]

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

I think you have misspelled "Scheme".

Re:Cross language - what .Net gets right

[K. S. Kyosuke]

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

[K. S. Kyosuke]

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.

Re:Cross language - what .Net gets right

[K. S. Kyosuke]

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

[Anonymous Coward]

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.

Worse than that, even today, you have to "write" assembly shims on zOS (aka MVS) to "extend" the OS to do tasks that are taken for granted on every other system on the planet. Heck IBM ships a library full of examples for doing exactly that.

Re:Cross language - what .Net gets right

[Anonymous Coward]

WinRT is just COM Attempt #3. It'll interop with .Net just fine. It's also pretty much dead at this point, and nobody learned it anyway, so don't bother with WinRT. .Net is a mature platform, and COM interop with .Net is stable. It's not terribly fast, but mostly that can be mitigated by using it appropriately. Hell, I've written .Net apps that use COM libraries on Windows Mobile, which is heavily constrained, performance-wise. (ARMv4i is a dog and someone needs to put it down, but it's popular for barcode scanners running WinMo 6.5.)

The most important performance consideration for using COM interop is knowing how non-.Net code works (pointers and memory allocation and other stuff that makes VB programmers shake uncontrollably). Also, if you're a VB guy, you're not using COM interop to the fullest because VB lacks the unsafe keyword. You simply can't write COM interop stuff beyond the most basic pieces in VB because it requires you to use safety-checked code. That's the only advantage C# has over VB, but it's a doozy. When you use unsafe (as part of a class or method declaration, or as a code block), you can freely use IntPtr objects (these aren't pointers to integers, they're 32-bit pointers stored as an integer in an object, and can be any kind of pointer, including void*). You should also define packed structs that match up with C structs defined in the Win32 API. These will translate through the COM interop layer much quicker, since they're pre-packed and don't have to be translated by the marshaller at runtime using reflection. (This can be done in VB. It doesn't require unsafe.)

Mostly, it comes down to knowing the code or API you're working with and not expecting non-.Net stuff to work like .Net does. If you instantiate umpteen bajillion COM objects, expect bad performance. .Net won't optimize it away for you. Meanwhile, if you write good code that uses COM objects appropriately within .Net, you won't have performance problems.

Re:Cross language - what .Net gets right

[KingMotley]

.NET (CIL) has the following languages:
VB, C#, Python (IronPython), PHP (Phalanger), Javascript (Multiple), ADA (A#), COBOL, F#, Ruby (IronRuby), Lisp (IronLisp), Eiffel, Clojure (ClojureCLR), Prolog (P#), and quite a few others.

Re:Cross language - what .Net gets right

[KingMotley]

I should add Scheme (IronScheme) and Perl (Niecza) to that list as well. I would add JAVA (J#) to that list, but well... Sun killed that.

Re:Cross language - what .Net gets right

[DdJ]

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.

I remember things being very easy on Unix until the advent of C++. As long as you were careful, I recall no problems interfacing between C and FORTRAN and Pascal and such. (You had to be careful because, for example, FORTRAN didn't understand the concept of pointers and dereferencing, so C code that didn't respect that could confuse the bejezis out of FORTRAN's optimizers.)

My old startup company (mid to late 1990s) sold a product with a C API. We integrated it with Perl, Python, Java, TCL, and PHP.

TCL was glorious at this. Once h2xs came into being, Perl wasn't bad (at least back in the days when nobody expected to do OO Perl yet). Python (1.5) wasn't bad at all. Even PHP was doable with a little work (it got easier later).

But C++ stormed ahead with overloading, and without a care for ABI compatibility -- you couldn't even assume the products of two different C++ compilers, or even two different versions of the same compiler, could be linked with each other, and it's all gone downhill from there.

I was going to give my opinion on the best approach for dealing with this, but there isn't one. The problem is, the best approach for maintainability is bad for performance (and vice versa). But my preference when one can get away with it is basically to do "RPC" over an I/O channel instead of attempting direct linking.

Re:Cross language - what .Net gets right

[TangoMargarine]

http://en.wikipedia.org/wiki/X86_calling_conventions#cdecl

Doesn't this count?

Re:Cross language - what .Net gets right

[gonz]

.NET also has a managed C++ model, which as allows C++ objects to be tightly bound to C# including garbage collection in an extremely natural way, while still having inline assembly language and all the performance of C++. And for managed languages (C#, VB, PowerShell, Python, etc) you get very deep integration that is probably the best that could be hoped fo. The F# mutability example is unreasonable, given the radical difference between these languages. And for all of this integration you get to use a single IDE with a visual debugger that shows you a single callstack with thr different languages mixed together.

Microsoft solved this problem so thoroughly, you couldn't ask for much else, except that none of it works on any OS other than Windows.

Re:Cross language - what .Net gets right

[Guy Harris]

http://en.wikipedia.org/wiki/X86_calling_conventions#cdecl

Doesn't this count?

It's an x86 calling convention (as the article says), not a generic calling convention for C for all architectures, as "blah blah blah is not a standard C parameter passing method" would speak of. There's no generic convention for passing parameters in C, there are only specific conventions for passing them on particular architectures, and most of those conventions do pass parameters in registers, although not all do (somewhat to my surprise, S/390 also passes parameters in registers), so x86, along with some rather old ISAs such as PDP-11, VAX, 68k, etc., may be the only ones that never pass parameters in registers, so "Passing in registers is not a standard C parameter passing method" is complete bullshit.

Re:Cross language - what .Net gets right

[TangoMargarine]

Well, the first line says that 'cdecl' stands for 'c declaration'...so calling a pig a pig...

Anyway, when I took an assembly course a couple years back, we referred to passing on the stack as "the C calling convention," so I suppose I'm probably overgeneralizing. Obviously you have to be careful when passing by register though, as many ops destroy register values so you can't expect them to retain their starting value when you return, unless you manually restore them inside the subroutine. I suppose that's a general observation of anything you do in assembly, though.

Re:Cross language - what .Net gets right

[TangoMargarine]

The course was specifically x86 assembly, so yeah, I concede your point.

Re:Cross language - what .Net gets right

[raddan]

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.

Re:Cross language - what .Net gets right

[raddan]

Believe it or not, CIL (or MSIL in Microsoft-speak), the bytecode for .NET, is an ECMA standard, and implementations of both .NET JIT'ers and standard libraries exist for practically all modern platforms, thanks to Mono. So I'd say: "competition for portable applications". Really! Just take a look at Gtk#. As a result, there are numerous applications for Linux written in .NET languages (e.g., Banshee). Having written huge amounts of code in both JVM languages (Java, Scala, JRuby, and Clojure) and .NET languages (F# and C#), I would take .NET over the JVM for a new project any day.

Also, to pre-emptively swat down this counter-argument: while the Mono people and Microsoft may have had some animosity in the past, it is most definitely not the case any more. Most of the Mono people I have spoken to (yes, in person) say that their relationship with Microsoft is pretty good.

Build systems and dependency management for the JVM are their own mini-nightmare. .NET's approach isn't perfect but compared to [shudder] Ant, Maven, Buildr, SBT, and on and on and on... it largely just works.

Re:Cross language - what .Net gets right

[raddan]

Exactly..

Re:Cross language - what .Net gets right

[Guy Harris]

Anyway, when I took an assembly course a couple years back, we referred to passing on the stack as "the C calling convention," so I suppose I'm probably overgeneralizing.

Yes - there's no such thing as "the C calling convention", there are just conventions for particular instruction sets and, as indicated, most of the conventions involve passing some parameters in registers.

Obviously you have to be careful when passing by register though, as many ops destroy register values so you can't expect them to retain their starting value when you return, unless you manually restore them inside the subroutine. I suppose that's a general observation of anything you do in assembly, though.

Yes, if programming in assembler, or developing a compiler, you have to make sure you know whether a register gets overwritten, but that's not specific to passing parameters in registers.

Re:Cross language - what .Net gets right

[angel'o'sphere]

Thats why some RISC architectures have register windows and register renaming :)

Re:Cross language - what .Net gets right

[Dahamma]

Not trolling. While working on an Xbox One app, Microsoft devs were clear that it does not and will not have support for CLR or .NET. They now seem convinced that everyone wants to write Metro/Modern apps in Javascript using WinRT.

So, "abandoned" is a bit strong, but there is a significant movement at Microsoft pushing for developing everything for Win8/WinRT/Phone/XBOne w/ WinRT. I'm sure it will exist alongside .NET for a long time but my point was why did they decide to go implement something different if they were embracing .NET as their long term multi-language, cross-platform development system?

Re:Cross language - what .Net gets right

[RaceProUK]

On Windows/WinPhone, you can use .NET for WinRT apps, so it'll go for some time yet.

Re:Cross language - what .Net gets right

[Anonymous Coward]

Entirely untrue. For starters, the CIL is significantly more abstract, to the point where a language does not exist which can and does implement all exposed functionality. Second, CIL internally contains many features that enable much more aggressive interop scenarios, such as native exports. Third, CIL also permits a mix of functions that are written in CIL and other binary formats, which is why standard c and C++ can be compiled as .NET assemblies frequently without any changes and the output assembly will be a mix of CIL and x86.

Also, your show to have little experience with WCF. While it is true that, out of the box, the binary transport relies on the binary formatter which is based on the binary serialization built into .NET and relies on CLR semantics, every single part of that is replaceable. You could use your own binary formatter, or one of countless others available. WCF is little more than an abstract framework for RPC. Whether you're using protocol buffers over UDP or CORBA or IBM MQ or Morse code over smoke signals it doesn't care.

Re:Cross language - what .Net gets right

[Anonymous Coward]

Er... whut?

Anyone who pays any attention whatsoever to .NET would not make such a statement. Abandoned? Are you kidding me?

In the last 4 years we've had two major framework releases. ASP.NET has been open sourced plus MVC is now on version 5 and Razor is the most elegant code/html intermingling framework around. 2 versions of Visual Studio, which is hands down the best IDE on the planet. The language has gotten LINQ, Lambdas, Async/Await.

They're retiring things that weren't going to catch on (silverlight), keeping things that will work (WPF/Metro)... oh and their dev tool stack now offers full featured support for node.js, we have intellisense in javascript, they've added NuGet for easy download/install of just about any plugin you would ever want to use, and the .NET platform still supports languages like IronPython, IronRuby, and there are extensions to use visual studio with PHP.

The Mono framework is fully supported, so you can run .NET apps on macs, linux, IOS, and Android. Unity3D is a great game dev studio that uses C#.

I mean, holy crap peeps, it's the golden age for .NET developers.

Re:Cross language - what .Net gets right

[shutdown -p now]

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 have the same bit representation in .NET as they do in native - calls are direct, with no marshaling overhead at all, it's literally a CALL instruction emitted by the JIT.

Re:Cross language - what .Net gets right

[shutdown -p now]

IntPtr objects (these aren't pointers to integers, they're 32-bit pointers stored as an integer in an object, and can be any kind of pointer, including void*).

IntPtr, aka "native int" (in IL), as the name implies, is not 32-bit - it's architecture dependent, and matches the size of the native pointer, like intptr_t in C99.

Re:Cross language - what .Net gets right

[shutdown -p now]

P/Invoke is basically the typical C FFI that many other platforms possess, with all the same advantages and disadvantages. .NET fares better than many on that front because the type system is flexible enough to closely match that of C with no need for translation (has pointers, structs and unions). That (and JIT compilation) is largely why it can be so low overhead.

Re:Cross language - what .Net gets right

[shutdown -p now]

You can add Java if you want - that'll be IKVM. It's JVM-bytecode-compatible, even (it dynamically translates it to IL).

Re:Cross language - what .Net gets right

[shutdown -p now]

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

CIL is low-level enough that a fully conformant ANSI C compiler can be written to target it. It has raw pointers, structs, unions and stack allocated arrays. It also has some things that C does not (like guaranteed tailcalls). All of those are highly efficient. I honestly don't know what else you could possibly need to write a compiler for whatever language you are interested in.

I know you meant lots of languages can be run in .NET, like VB.NET or C# or F# or IronPython, but really they are just syntactic sugar on top of the underlying bytecode. All that is different is the words used to code up your program, some have curly braces, some have BEGIN/END.. the difference is superficial.

It sounds like you've only actually looked at C# and VB.NET, which are, indeed, largely the same thing with slightly different syntax.

But have you actually looked at IronPython? It's not "just syntactic sugar", it's a full fledged Python implementation that has every single language feature that regular Python 2.7 does (it doesn't have the entire standard library, but there's no reason why it couldn't).

Long story short, your argument is false because of the point above. CIL is flexible enough for any language to target it without the need to adapt it. You may need language extensions if you want to interop on object model level (i.e. classes and objects, rather than primitives and structs), but it's not a requirement.

Re:Cross language - what .Net gets right

[Anonymous Coward]

It depends of implementation if P/Invoke is substantially faster than COM interop... compilers with good COM support can do direct calls to com servers, and offer language runtimes that reduce the runtime com stack used, linking compiler optimized replacements to system calls, allways closely following the binary com standart. Read about good old DirectCOM in BlackBox from Oberon Inc or the ObjectArts Dolphin SmallTalk for flexibility and dinamism, or the current PowerBasic support to COM for speed and easy of use. dotNet isnt as fast or nice if you know where to look at

Re:Cross language - what .Net gets right

[Anonymous Coward]

I read it like if he was talking about P/Invoke and COM

I almost feel WinRT some how like C++ only COM with XML dotNet style metadata instead of COM IDL/ODL generated TypeLibrarys

My read is that DeveloperTools division dotNet lost the technical battle with WinOS division after the longhorn fiasco and threfore the not clr based WinRT

Re:Cross language - what .Net gets right

[Anonymous Coward]

The Python and Ruby extensions for .NET are more or less dead.

Python on the JVM is dead also but not Ruby

Re:Cross language - what .Net gets right

[Anonymous Coward]

The JVM had support for multiple language since before .NET existed.

The JVM language list is far longer than the .NET list and ditto for the list of currently supported languages.

The JVM has the advantage of being fully and officially supported on more platforms.

mono suck balls

Re:Cross language - what .Net gets right

[Anonymous Coward]

What is modern about it?

Looks like AOL circa 1996

Re:Cross language - what .Net gets right

[Anonymous Coward]

What is modern about it?

Re:Cross language - what .Net gets right

[Anonymous Coward]

mono is not fully suppoorted as it is a third party framework and a subset of .net.

Retarded troll is retarded.

this kind of comment system is dead

[Anonymous Coward]

every language but c and go suck

thats a fact

Re:this kind of comment system is dead

[narcc]

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

[stenvar]

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

[kthreadd]

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

[serviscope_minor]

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

[serviscope_minor]

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

[kthreadd]

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

[narcc]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[kthreadd]

Not to mention C++14.

Re:this kind of comment system is dead

[Anonymous Coward]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

Re:this kind of comment system is dead

[narcc]

What about C++11?

That's my point entirely. :)

Re:this kind of comment system is dead

[stenvar]

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

[ustolemyname]

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.

Re:this kind of comment system is dead

[ebno-10db]

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

That's why the D language was developed. 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

[ebno-10db]

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:this kind of comment system is dead

[Anonymous Coward]

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

[ebno-10db]

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

[kthreadd]

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

[kthreadd]

GTK+ is written in C but it offers bindings for many other languages including C++. This is very easy since C has good interoperability.

Re:this kind of comment system is dead

[Anonymous Coward]

From which language?

Are you comparing using GTK+ from C with using e.g. QT from C++? That's not really a useful comparison.

If you have a C++ application, QT may very well wobe nicer than GTKMM. But if you have a C application, GTK+ is likely to be nicer than QT. And until proven otherwise, I expect that the advantage of GTK+ over QT is larger in a C program, than the advantage of QT over GTKMM in a C++ program.

The biggest advantage of a C based toolkit is that adding bindings for any language is easy. Adding bindings for any language (including ones that aren't object oriented) to a C++ based toolkit is going to be complex, and will likely ruin all the things you find nice about a C++ based toolkit.

Re:this kind of comment system is dead

[Anonymous Coward]

It's "very easy" because Gtk+ has defined their own type system on top of C.

Re:this kind of comment system is dead

[ebno-10db]

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.

But who uses it for anything other than legacy code? Even the DoD dropped their mandate 16 years ago. F-22 software is written in Ada, but F-35 software in C++ (remind me to find deep shelter if I'm ever near an F-35 base).

Old languages (even if they've been updated like Ada) that never really caught by a certain point almost always die, even if very slowly. A newer language has a better chance. It's more of a sociological issue than a technical one, but that doesn't alter the reality of it.

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

Because sometimes my Nomex underwear was in the wash. Back when people had heard of it, any mention of Ada brought all sorts of ignorant criticism and flaming. Eventually I got tired of the argument. I knew I was right, and to hell with anyone who didn't realize it :)

Re:this kind of comment system is dead

[serviscope_minor]

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

No, I saw it. He's wrong AND his reasons are crap.

I don't know why you're so defensive of the language.

I'm not. I use C++ a lot and I quite like it. If you have an open mind, I'll happily bore you to death with all the things I hate about C++ and why I wish they were better.

It is however impossible to have a sensible discussion about C++ with people who know almost nothing about it yet strongly hold opinions about it out of some misguided sense of fashion.

C++ hasn't exactly improved over the years.

Which is yet another statement which strongly indicates that you don't actually know anything about C++. If it turns out you do use it, then contratulations: you've managed to isolate yourself from reality.

Again, I could happily bore you with all the many things that have changed for better or worse up to 1998, between 1998 and 2011 and the merits and demerits of C++ 11 and C++14.

But you hold your opinions firmly and out of ignorance so it would be a complete waste of time on my part.

Re:this kind of comment system is dead

[ebno-10db]

And the English language suffices for bad puns (though I understand Mandarin is even better).

Re:this kind of comment system is dead

[serviscope_minor]

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

Same reason lisp ultimately never catches on. If you work with other programmers then you have to communicate with them.

You can do almost everything in C that you can do in C++, but you have to do it by hand. But in C you have to do everything by hand and everyone does everything slightly differently.

It's useful to have the class notion baked into the language for the same reason it's useful to have the for loop baked into the language. It reduces overhead to read and write and makes the common case much less error prone.

Re:this kind of comment system is dead

[serviscope_minor]

Yes, bad user interfaces and mish-moshes of barely portable shell and C are the hallmarks of a good design.

Fair enough. I was not an early adopter. I gather it was really not very good in the early days until someone wrote some moderately sane UI code to go around it. The main reason I use it instead of mercurial is momentum: git is popular with OSS so I had to learn enough to get by. Then it because a question of learning another system (Hg) or sticking with something moderately familiar.

Git is very good in that it works well for a lot of people. It's not necessarily the best :)

Re:this kind of comment system is dead

[ebno-10db]

Same reason lisp ultimately never catches on.

I wanted to start a flame war for fun, but you're throwing rocket fuel on the fire. Using that four letter word practically guarantees a conflagration.

Re:this kind of comment system is dead

[ebno-10db]

The main reason I use it instead of mercurial is momentum: git is popular with OSS so I had to learn enough to get by.

Ditto. It's just that it's always a sore point with me when an inferior design wins out for silly reasons, especially when I have to live with the inferior product. But it's hardly important enough for me to spend the rest of my life decrying the injustice of Git winning over Hg (10 or 20 years of ranting should suffice).

Re:this kind of comment system is dead

[larry bagina]

Facebook started using D a month or two back.

Re:this kind of comment system is dead

[Anonymous Coward]

It reduces even more overhead if you simply don't uses classes and objects. It also makes your life much easier and your code more readable and maintainable.

Re:this kind of comment system is dead

[ebno-10db]

Nice! I hope it sees widespread use there because, like I said, that may be about the only way the language will really catch on. Right now I get the feeling a lot of people either don't know or don't care about the language, because I every time I mention it here there's almost no reaction. A flame war would be better than ignoring it.

BTW, I've only recently started using it, although I've known about it for years. From what I understand, up until fairly recently, it had some rough edges. They seem to have been polished D2 has completely superseded D1, the old Phobos vs. Tango library issue is gone (only Phobos now - Tango is thankfully dead).

The one thing that seems to still need some polish is the GC implementation. Right now they have a "stop the world" GC, but someone is porting the Boehm GC. Currently alpha, but looks good.

Re:this kind of comment system is dead

[Anonymous Coward]

No need to use malloc/free,strcpy,strlen and only rarely memcpy (if at all). You just have to return/accept raw pointers (and quickly wrap them) or convert things from and to std::string, std::vector (a single method call). Worst case you pass function callbacks with void* and cast them (to pass your c++ callback objects). The result has very few lines that are stuck in the dark ages, the rest is nice/safe c++.

Some languages care and give you an already c++ like interface (JNI) when you want it.

Re:this kind of comment system is dead

[donscarletti]

C++ is indispensable for 3d engine programming for the following reasons.

• You tend to use a lot of refcounting here and there to manage freeing of resources. C++ through constructors, destructors and operator overloading means it is hard to screw this up unless you try. Even when you don't need refcounting, you can use auto_ptr or something to make sure something's freed when it needs to be. I used to have memory leaks or heap corruptions regularly when using C, with C++ I run into that stuff maybe yearly.
• A lot of the most time-sensitive inner loops tend to need to work on multiple different types of buffers, like manipulating different vertex formats, different bitdepths/formats of textures, different lengths of index buffers, etc. Template functions let you write this in a way that will execute just as fast as if it was using define macros, but far easier to read and maintain, meaning one no longer has to choose between maintainability and efficiency, the easy way is also the right way.
• Mostly, the OO model fits really well. An "object" represents something that more or less actually behaves like an actual real world object with various behaviours peculiar to that type of object, that need to fit together in a heterogeneous collection of other objects in the scene graph. You can do this in C, but maintaining vtables and such gets tiresome and problematic. C++ makes this all rather easy.
• STL once again makes the easy way the right way. Using quicksort to sort a list, using red-black trees to store a dictionary, using a dynamically resizing vector to store an unknown length array is actually easier to implement things in the asymtotically efficient way and safe way than to do things in an inefficient or dangerous way. Stack/heap over/under runs are rare, since buffers can be allocated dynamically without the programmer even thinking about it. Templated functions and classes in the STL allow you to use your fastest data structures and algorithms wherever you like for less effort than it takes to write a bubble sort. You can re-arrange an array of any object you like into a heap in a single line without a single function call or malloc.

Re:this kind of comment system is dead

[narcc]

auto_ptr has been depricated

Re:this kind of comment system is dead

[donscarletti]

Fine, unique_ptr then. Regardless, auto_ptr was only ever 10 lines of code, if it was to be removed completely, it could still be re-added in 2 minutes. Point is, in C++ you can write pointers that free themselves. Destructors are super useful for everything, I use them to free all kinds of memory, as well as to release mutexes and stop timers when the it returns, breaks or gotos out of a block.

Re:this kind of comment system is dead

[microbox]

You do realize that you can read and write C interfaces in C++. And you also get all the goodness of C++, which is a lot if you actually know what you are doing. The only real problem with the language is that it takes too long to learn how to use properly. But that also means that C++ developers are generally smart.

Re:this kind of comment system is dead

[microbox]

You're right. We should all eschew C++ for C, because the bindings to foreign-function interfaces don't require you to write extern "c" {}.

Re:this kind of comment system is dead

[angel'o'sphere]

C++ is not a superset of C, since minimum a decade.
There are plenty of examples of valid C programs that don't compile in a c++ compiler, google and stackoverflow are your friend.

Re:this kind of comment system is dead

[shutdown -p now]

Whether D is something that's "done correctly" is, shall we say, extremely arguable.

Re:this kind of comment system is dead

[Anonymous Coward]

As someone of Linus's approximate age & computer science generation, I suspect part of his hate comes from the fact that we were the generation that got the C++ rug pulled out from underneath us and got totally screwed by it while we were in college. Older guys graduated before C++ was relevant, and younger guys managed to avoid the ~5 year period of miserable limbo in the late 80s/early 90s when everything your textbook and professor taught and tested you on was literally WRONG as far as any C++ compiler and IDE you actually cared about (read: Borland or Watcom) was concerned.

Few things can top the demoralization that comes from getting "A" after "A" on projects all semester long, then failing the final exam because the professor's grad assistant marked every goddamn code question wrong where you used ANSI syntax, and you had to literally get the dean involved to negotiate with the professor and convince him to at least give enough partial credit on those questions to end up with a "C" for the semester.

It took me YEARS to get over my total hatred of C++ thanks to that class. For the remainder of my undergrad years, I bent over backwards to write everything in m68k assembly language whenever possible, just to avoid having to use C++.

Re:this kind of comment system is dead

[shutdown -p now]

The price for that is the major pain that using countless macros to implement your "classes" is in GObject, where the same thing in C++ is literally a single line of code.

Re:this kind of comment system is dead

[stenvar]

Let me explain, since you seem to have a bit of trouble with the history and usage. C++ has never been a strict superset of C as a language; there have always been C programs that were not valid C++ programs. Therefore, when C++ programmers say that "C++ is a superset of C", it always means that you can take any C program and with only small modifications turn it into a valid C++ program that works and links the same way as the C program you started with.

Re:this kind of comment system is dead

[angel'o'sphere]

Well, *once* C++ was a *real* superset of C.

Your claim here is bogus, you just try to not lose face, rofl.

Afterwards I guess it started mid 90th the designer deliberately broke stuff and made it noticeable different in C++. So I would say porting badly written C (especially K&R C) to C++ is not as easy as you seem to believe.

Re:this kind of comment system is dead

[TheRaven64]

C++ was never a superset of C. The following code has always been valid C and never been invalid C++:

int class = 42;

There are numerous other examples. The interesting behaviour of sizeof() when you have a class and a variable of the same name is one of my favourites.

Re:this kind of comment system is dead

[Anonymous Coward]

Well, *once* C++ was a *real* superset of C.

Nope, sorry, see TheRaven64's response. Really, this is trivial stuff that any C++ programmer ought to know.

Re:this kind of comment system is dead

[ebno-10db]

Ok, argue it.

Re:this kind of comment system is dead

[shutdown -p now]

Why the difference between "int function(int)" and "int delegate(int)"? Why not a single type for callables?

Re:this kind of comment system is dead

[david_thornley]

Don't forget the template system. While it can be very tricky to write for, and error messages are often bad, it's dead easy to use. std::sort is not only easier to use than C's qsort(), it's very often more efficient because it doesn't require as much indirection. The STL idea is very powerful.

Re:this kind of comment system is dead

[stenvar]

I have decidedly mixed feelings about the template system. C++'s implementation of templates is a bit brute force but very efficient, and that's nice to have around.

But I think neither its template system nor the STL are particularly well designed.

Re:this kind of comment system is dead

[Anonymous Coward]

Calling C++ code from any other language is a cast-iron bitch.

C is trivially easy.

Re:this kind of comment system is dead

[Anonymous Coward]

When C++ programmers claim C++ is a superset of C they are proving their ignorance.

C++ intersects with C.

Any programmer that doesn't understand set theory should close shop and go back to flipping burgers.

Re:this kind of comment system is dead

[Anonymous Coward]

Try to inteface C++ and (Ruby || Python || Java || Go || *)

Re:this kind of comment system is dead

[Anonymous Coward]

Why the difference between Ruby's Proc & lambda?

Re:this kind of comment system is dead

[shutdown -p now]

Because the semantics of the body are different - one also closes over the control flow (i.e. the meaning of break and return), the other one does not.

Re:this kind of comment system is dead

[Anonymous Coward]

more bloated != improved

Re:this kind of comment system is dead

[Anonymous Coward]

Fog Creek seamlessly supports mercurial and git. I use hg for day to day and when I need to push to a git repo like GitHub it is trivially easy to do so.

Re:this kind of comment system is dead

[david_thornley]

C++'s template system is roughly equivalent to Lisp macros, which are elegant and incredibly powerful but hard to work with, in a much more awkward form. The STL, on the other hand, looks generally well designed to me. It takes a few basic concepts (containers, iterators, algorithms) and puts them together in very useful ways. What problems do you see with it?

Re:this kind of comment system is dead

[stenvar]

No, C++'s template system is nothing like Lisp macros. Lisp macros were straightforward tree rewrites. C++'s template system interacts in very complicated ways with overloading, inheritance, and other language features.

As for STL, its basic notions of containers, iterators, and algorithms exist in most languages and predate it by a couple of decades. STL is bloated and complex in comparison. The justification for the additional complexity in STL was efficiency, but STL isn't actually significantly better than simpler designs.

Re:this kind of comment system is dead

[Anonymous Coward]

It means that C++ programmers don't understand set theory.

Re:this kind of comment system is dead

[david_thornley]

C++'s template system is equivalent to Lisp macros in that both give compilers a Turing-complete way to generate code. I'm not claiming that it's anywhere near as elegant.

I'd be interested in knowing what languages in common use had something equivalent to STL containers, iterators, and algorithms, and what that was. I know a bit about computer languages, and I don't know of anything actually equivalent. The complexity is mostly on the implementation end, not the use end, and I don't see why you say it's bloated and complex.

Re:this kind of comment system is dead

[stenvar]

C++'s template system is equivalent to Lisp macros in that both give compilers a Turing-complete way to generate code. I'm not claiming that it's anywhere near as elegant.

Even printf+system("cc") is equivalent to the Lisp macro system at that level; we've been talking about language design.

C++'s template system was not intended as a Turing-equivalent compile-time code generator; that was something people figured out over time. In fact, many people saw that early on but refrained from using it because compilers couldn't handle it; they took it more as a sign that the C++ designers were screwing up than as a good language feature.

I'd be interested in knowing what languages in common use had something equivalent to STL containers, iterators, and algorithms, and what that was.

OCAML, F#, SML, CommonLisp, Smalltalk, Python, to name just a few. STL is a poor imitation.

The complexity is mostly on the implementation end, not the use end, and I don't see why you say it's bloated and complex.

Most of the algorithms and data structures it provides have don't belong in, and aren't useful in, in a general purpose library. And STL's pointer-like iterator abstraction makes things that should be easy to express in a container library tedious and cumbersome.

Context is an island somewhere:

[Zanadou]

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

decouple... SOA

[Anonymous Coward]

That said.... C rules!

Re:decouple... SOA

[ebno-10db]

The joy of a least common denominator.

Java, all you need.

[magic maverick]

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.

[Anonymous Coward]

Gods damn, THIS!!!

Re:Java, all you need.

[Anonymous Coward]

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.

[Anonymous Coward]

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.

[texwtf]

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.

[Anonymous Coward]

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

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

[Anonymous Coward]

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

Re:Java, all you need.

[Anonymous Coward]

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.

[Dahamma]

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.

[Anonymous Coward]

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*

Re:Java, all you need.

[ebno-10db]

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.

[ebno-10db]

but in order for java to be cross platform

Java is portable in the same sense that you'd be portable if you traveled with your own hotel.

parent is obviously trolling...

Or parodying.

Re:Java, all you need.

[Anonymous Coward]

This is either proving the point, or possibly a kind of ultra-subtle ironic joke. I honestly don't know.

Re:Java, all you need.

[Anonymous Coward]

The word you're looking for is "oriented", not "orientated". You don't orientate things, you orient them. Thus to orient a coding style toward using objects is called an object-oriented style. If you can't spell it right, shortening it to "OO" will prevent you from looking like a moron.

Also, Java is terrible.

For managed languages, C# beats it hands down. For "real" languages, there's nothing quite like C. For everything else, there's an obscure academic language. Java is irrelevant, and has nothing but inertia at this point. All other advantages have been stripped away. Watch closely in the next few years. Oracle will piss everyone off, then Java will disappear.

Re:Java, all you need.

[Anonymous Coward]

As an American, I fully agree. Americans are not only rather slow (you might say "thick" on your side of the pond) in general, but they sure do get defensive when someone makes fun of them and their idiotic ways.

Can someone point me to resources to emigrate to Europe and get away from this land full of right-wing idiots?

Re:Java, all you need.

[mjwalshe]

Then why does Hadoop come with support for many other languages rather than bloody Java :-)

Re:Java, all you need.

[mjwalshe]

you win the inter webs this week for "Java is portable in the same sense that you'd be portable if you traveled with your own hotel."

Re:Java, all you need.

[Anonymous Coward]

http://www.aa.com/

They sell one-way tickets. Please buy one.

Java and C++ is not a simple example

[Anonymous Coward]

I hope JNI burns in hell

Java, C++

[stenvar]

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

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

Re:Java, C++

[abies]

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

[stenvar]

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.

Re:Java, C++

[Viol8]

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

[stenvar]

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

[ebno-10db]

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.

Re:Java, C++

[ebno-10db]

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

Re:Java, C++

[RabidReindeer]

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.

Re:Java, C++

[RabidReindeer]

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.

Re:Java, C++

[serviscope_minor]

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

Well done! You defeated that straw man with aplomb! Go you!

You -speficially- mentioned the C++ runtime. I pointed out one particularly notable aspect of the runtime where they did indeed make the correct choice.

Apparently your brain has invented the throught that this means I agree with every decision the C++ committee made about every bit of undefined behaviour ever.

I have a suggestion for you: before laying on the sarcastic comments, you may find it useful to actually read the post you're responding to.

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.

Depends what you mean by "best choice". The thing is many C+ programmers (myself included) would love to chuck out the backwards compatible crap and have the nice aspects of C++ come to the front except (and this is a HUGE except) we don't really because code written in 1998 still for the most part works.

I regularly use a library that's been in version control since 2004 (nearly 10 years) but was developed for a considerable time before that. Some of it is excellent, some of it is not pretty. Some of the old, ugly code still works perfectly however. It's arguable whether the "right choice" for C++ could ever to remove significant amounts of backwards compatibility since one of the primary advantages of C++ is stability.

I use C++11 now daily. All my new code is written in the nice subsed that C++11 now affords. Sadly, if they had broken significant amounts of backwarsd compatibility, I'd still be stuck on C++98.

TL;DR Keeping cruft for backwards compatibility sucks. Breaking backwards compatibility also sucks.

Re:Java, C++

[serviscope_minor]

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 code with exceptions enabled and not to see what the difference in speed is. I believe the new method is essentially zero cost on the non exception path now. A good link is:

http://mortoray.com/2013/09/12/the-true-cost-of-zero-cost-exceptions/

In terms of embedded code... yeah dunno. My guess would be that the cost of every exception could be computed in terms of cycles since the lookup process will be the same and you can compute how much code is being run in the desctuctors. It probably would be tricky to actually do however.

Re:Java, C++

[dkf]

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.

Re:Java, C++

[ebno-10db]

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 in foo(), guarantee that? Would the compiler be smart enough to figure it out and take advantage of it?

Re:Java, C++

[ebno-10db]

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

Basically that's saying it's not very flexible. There are languages that are safe by default, but allow you to do "unsafe" things where necessary, and make it very clear that something unsafe is being done (requires an "unsafe" pragma or something). If a given project shouldn't need any unsafe code, you can easily ensure that it doesn't.

Re:Java, C++

[serviscope_minor]

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 in foo(), guarantee that? Would the compiler be smart enough to figure it out and take advantage of it?

For better or worse, nothrow is not checked: you can call a plain function from a nothrow one (IIRC) which will cause an abort if the exception passes through the nothrow one. If a function is nothrow() then it looses its ability to propagate exceptions so really no overhard is incurred.

In terms of proof: the compiler won't do it, but it takes your word for it that no exceptions will pass through it. It would be nice to have some way of verifying that statically.

Re:Java, C++

[Rockoon]

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

Well a lot of programmers seem to use exceptions for normal/common flow control. You can declare them to be bad programmers, but the code is never-the-less in the wild as part of libraries and frameworks.

For instance, this behavior is all over the collection of stream classes in .NET. This has resulted in there being no way to reliably determine that there is still data in a non-specific stream other than trying to read from it and catching an end of stream exception. You either end up with code that only works with some kinds of streams but not others, or you use god damned exceptions for flow control.

(at this point some defenders may come in and say "just check if the streams position is greater than length" -- only works on streams that have a length, or the might say "just see if peek returns -1" -- only works on streams that support peeking, and so on...)

Re:Java, C++

[ebno-10db]

Well a lot of programmers seem to use exceptions for normal/common flow control.

When I first learned about exceptions, they came with the strong advice not to use them for normal flow control. Naturally I had to try it for myself, and quickly learned that was excellent advice. No language is idiot proof.

Re:Java, C++

[stenvar]

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.

No, that's not what is "really happening" at all. Supporting direct native calls in the JVM would impose no cost on Java calls at all; it would be completely separate instructions.

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

Yes, it really matters.

Re:Java, C++

[Anonymous Coward]

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

Yes, but there is no JVM or JIT support, and it's not a standard part of the platform.

Yes, but that's not always a big problem.

But it often is a big problem, and that's what matters.

Well done! You defeated that straw man with aplomb! Go you! You -speficially- mentioned the C++ runtime. I pointed out one particularly notable aspect of the runtime where they did indeed make the correct choice.

Well done! You put up another straw man. I'm not even going to bother responding to this kind of nonsense.

Re:Java, C++

[stenvar]

There's a reason. Java wasn't designed to be unsafe.

If you need to call native code, JNI is even less safe than providing unsafe primitives in the Java language itself would be. That makes Java's design either poor, or it is a feeble attempt to discourage the use of unsafe modules by making them cumbersome or inefficient.

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

Yes, and that makes Java a bad choice for lots of applications.

Re:Java, C++

[stenvar]

They're trying to save you from yourself, or from the most inept programmer you have

Yes, a lot of bad design decisions in Java are driven by ineffective attempts to keep programmers from doing bad things. What keeps my most inept programmer from writing a bad JNI module?

A simple and effective approach, which other languages use, is to have anything that's unsafe include "unsafe" in their name

That's good, but there's one more thing: the compiler and runtime need to keep track of which modules use unsafe primitives and expose that both to the language and the loader. That is, an unsafe Java module should be treated like a JNI module, except that it's more portable and written in a language Java programmers already understand.

Re:Java, C++

[Anonymous Coward]

That ould never have happened if the rnutime was heavily specified.

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

hek your keyboard for soe issing keys.

Re:Java, C++

[TangoMargarine]

...tools like Swig make even...

This whole problem sounds like it would be eased somewhat by a few large swigs :)

Re:Java, C++

[angel'o'sphere]

Java's JNI is poorly designed and makes no serious attempt to make interoperability easy because it is against Java's philosophy. So speaks a guy who has no clue :-/
You know that Java is a GCed language where objects even move around?
JNI is designed to solve or tackle at least a lot of "problems" the commoner like you does not think about.
For nearly EVERYTHING you find "complicated" in Java there is a damn good engineering reason behind it. When you once have more than 30 years programming experience you will understand why some designs look complicated on the first glance.

Re:Java, C++

[angel'o'sphere]

Don't get what you are talking about.
I Java it costs you mothing to make a native call.
And in fact there is a special instruction for that.
You simply define the called function as 'native' ....
The hard part is on the CALLED SIDE! There you have to use JNI to write a wrapper over your called function. Also it takes some effort to call Java methods back from the native side.

Re:Java, C++

[angel'o'sphere]

So called "zero cost exception handling" we have since over a decade.
See here: http://stackoverflow.com/questions/691168/how-much-footprint-does-c-exception-handling-add
or google yourself ;)

Re:Java, C++

[angel'o'sphere]

If you don't actually use exceptions, there should be no difference anyway. Hm, but perhaps enabling them and not using them indeed also left some stack manipulation behind. Don't remember :-/

Re:Java, C++

[angel'o'sphere]

With so called zero overhead exceptions you have definitely no overhead at all when you don't throw one. You have a small potential overhead when the tables at program start get initialized.
Keep in mind: passing error information over several levles of function calls certainly is not "zero cost".

My previous project was an embedded project in the automotive industries. They used exceptions ... your situation might be different.

Re:Java, C++

[ebno-10db]

A decade, huh? That means many of the compilers intended for embedded work should get the feature in 5-10 years.

Mostly I work w/ DSP, but often have a mix of DSP and "regular" code. The compilers tend to be very good in terms of optimization where it counts most in that work - loops, arithmetic, etc. They even do a good job w/ optimization that uses specialized architectural features that are common in such processors. The compilers are had to beat even w/ assy. When it comes to keeping up with standards and tricks like this (like I said, people are used to turning off exceptions for deeply embedded stuff) they're pathetic.

Re:Java, C++

[RabidReindeer]

There's a reason. Java wasn't designed to be unsafe.

If you need to call native code, JNI is even less safe than providing unsafe primitives in the Java language itself would be. That makes Java's design either poor, or it is a feeble attempt to discourage the use of unsafe modules by making them cumbersome or inefficient.

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

Yes, and that makes Java a bad choice for lots of applications.

EVERYTHING is a bad choice for some application. Only a small child with a hammer - or a silver-bullet seeking PHB - thinks that one tool can solve all problems.

The last time I needed to talk outside the JVM was in the last century. That's because I'm not presently writing device drivers, Interrupt Service routines or other functions outside the scope of general web business apps.

I was one of the very first to field a C++ compiler product, but I haven't written any C++ in years, because I prefer working on a platform with a rich, if occasionally warty set of standardized pre-debugged classes. For quick-and-dirty I use Python or Perl (for regex-intensive stuff) on the command line and PHP on the web.

I have no illusions that there is a "perfect" language for all things, but I really do get annoyed when people make claims about alleged inefficiencies without numbers to back them up, anecdotes of obsolete platform implementations or gross misuse by people who would be equally incompetent in any language or on any platform.

Re:Java, C++

[angel'o'sphere]

Most embedded programmers are meanwhile back to using gcc. I'm by no means an expert regarding that, but seems it beats many vendor specific compilers as well as the more general ARM targeting compilers.
As I said before my previous project was embedded. They where in the process in moving from TI's ARM compilers to gcc, when my contract ran out.

Re:Java, C++

[Anonymous Coward]

PRogrammer automation(productivity)!

Re:Java, C++

[suutar]

This is one of my main issues with Python. It still creeps me out that the standard loop termination method is an exception. But it sounds like they've optimized that path enough to not hurt.

Re:Java, C++

[Anonymous Coward]

JNI is designed to solve or tackle at least a lot of "problems" the commoner like you does not think about.

Only someone as ignorant as you would think that java's solutions to these "problems" is a good thing.

When you once have more than 30 years programming experience you will understand why some designs look complicated on the first glance.

And some people with 30 years experience still have learned next to nothing. Look in the mirror

Re:Java, C++

[shutdown -p now]

The C++ standard doesn't even have a concept of a "binary" (or, for that matter, "dynamic linking").

Re:Java, C++

[shutdown -p now]

In Python, "exceptions" is really a misnomer - they are a generic non-local return flow control tool, there's nothing exceptional about them - and the VM design reflects that.

Re:Java, C++

[stenvar]

I Java it costs you mothing to make a native call. And in fact there is a special instruction for that.

When wrapping native code libraries in Java, there usually needs to be glue code. That glue code needs to be written in C, since there is no JVM support for unsafe instructions. That means for every function in the native library, there are two C function calls involved: one from Java to the glue code, one from the glue code to the actual library. If one could write the glue code in Java using JVM instructions, the glue code would get compiled to native code by the JIT and the overall overhead for calling a function in a native code library would be just one function call, not two. Yes, this matters in practice. In addition to the speed advantage, writing the glue code in Java would also make it more portable and make it easier to deploy, which matters even more.

Re:Java, C++

[stenvar]

EVERYTHING is a bad choice for some application. Only a small child with a hammer - or a silver-bullet seeking PHB - thinks that one tool can solve all problems.

True, but that doesn't mean that every language design is equally good. Java has some serious design problems that could have been fixed without making it more complex and without affecting its utility for its current user population. In addition, Java ended up not being used for the purpose it was designed and intended for.

The last time I needed to talk outside the JVM was in the last century. That's because I'm not presently writing device drivers, Interrupt Service routines or other functions outside the scope of general web business apps.

Indeed: Java has become a specialty language for web applications. It failed at its original aspirations of becoming a language for general purpose desktop computing or for secure, sandboxed computing.

Re:Java, C++

[angel'o'sphere]

The question (as a language / VM designer) is: what do you want?
You can not have a "save language" with "unsafe instructions to write glue code" ... either you are safe or you are unsafe. You could argue: as soon as you can jump into C, you are unsafe anyway. However pure Java would become unsafe, too.
Bottom line your argument writing the "glue code" in Java to be portable is wrong anyway.
The glue code is the thing which makes it possible to interop Java on one side with C/assembly on the other side in a portable way! Usually you only have to recompile the glue code (and link it with the code you want to call).
The problem why you can not write the gluecode in Java portable is very simple: you know nothing about the target architectue where the code will run. You don't know anything about your VM which will execute your code. You know nothing about registers (or do you want to have a VM that has a set of unsafe opcodes for any "thinkable" architecture?) So the VM has to save its own state anyway, regardless of your glue code, before executing it. You know nothing about the calling conventions ... so how do you write glue code that works on a SPARC (using register calling conventions) and works on an x86 (using the stack)? You know nothing about the stack anyway, which register is the stack pointer, oh on x86 this is fix, other processors have more freedom, they can use more than one register as the stack pointer.
Then again: you know noting about the primitive and pointer data types the underlying hardware is using, so how do you write gluecode in a portable way that passes e.g. a "C long" from Java to C? Oh ... in Java a long is 64 bit. Many Cs have a long as 32 bit. Other Cs use "long long" for a 64bit "int" and again some Cs make "short" == "int" == "long". All this are reasons to make the glue code in C. And all this is supported by the JNI "header files" and glue code generators.
Because there we have "typedefs" or more precisely "#defines" for "portable" transfer and conversion of Java primitives into the correct C data types for the platform you are compiling the C code on!

Hint: JNI is a STANDARD, an API! Every JVM implementor who wants to use the trademark Java(tm) has to implement the JVM side of this API in order to be able to use the Sun provided JNI header files and stub code generators. Microsoft stumbled over that with their JVM that did not implement JNI.

The point of JNI is: if I have the gluecode (in C), then I only need to recompile the gluecode on/for the target platform once. Regardless of VM (vendor, word size, OS) and any VM on this platform will be able to access my native code. Granted: it is a bit cumbersome the first time you work with JNI, but later when you have shot yourself often enough into the foot, you realize how smart the inventors/designers in fact where.

Re:Java, C++

[Anonymous Coward]

Really, providing interfaces to shared libraries from high level languages isn't rocket science. Lots of languages do it, safely and portably. Java has JNA, which does the same thing, just not efficiently. For you to try to argue that this isn't possible is just stupid.

Re:Java, C++

[david_thornley]

Not quite. First, "nothrow" is something you use for a constructor, indicating that a constructor failure will return NULL (or, now, nullptr) rather than throwing if it fails. You're looking for "throw" or (with C++11) "noexcept".

Second, anything checked will have some baggage, and having an abort when an exception is thrown does require checking. This is why the old throw() wasn't what it looked like: it needed an exception block and a catch block that called std::terminate() or std::unexpected().

Third, there is no "the compiler" in C++. I generally use g++ or clang or Visual C++ myself. The compiler is required to do some checking of exception specifications, and may do as much as it wants. It isn't possible to do full static verification, though, since it is in general impossible to tell whether a given throw will be executed, and it is legit for a function to call another function that might possibly throw an exception it won't accept.

Re:Java, C++

[Anonymous Coward]

Sure, but sadly: Eiffel, Modula3, Ada, Oberon2/BlackBox and the like, arent as popular as they deserve for some reason... so we are stuck with c++ and java/dotNet

Sort of

[EmperorOfCanada]

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

[Anonymous Coward]

Nice theory!

Re:Sort of

[Anonymous Coward]

Fragmment te codebase in multiple languages just when it saves efford...
integrate some Fortran library instead of homebuilding some c++ a like
integrate some Prolog library instead of homebuilding some c++ a like
programing languages have their strong points and integration should be
posible, giving better results than reinvent the weel in the one true language

But really, good language independt integration standarts permits much
better, varied, cheaper, components, tools and librarys market. Permits
providers offer products serving multiple development enviroments... not
boring walled garden official parned based protected stores of nowadays

SWIG is awesome

[Anonymous Coward]

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

[Anonymous Coward]

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

[MikeTheGreat]

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

[serviscope_minor]

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

[Anonymous Coward]

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

[gigaherz]

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

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

[elfprince13]

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

[PolygamousRanchKid]

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

[Anonymous Coward]

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

In the back of a Volkswagen?

Java, a horrible horrible language.

[Kjellander]

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.

[kthreadd]

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.

[Anonymous Coward]

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.

[zwei2stein]

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.

[Anonymous Coward]

Agreed!

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

Re:Java, a horrible horrible language.

[Anonymous Coward]

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

Re:Java, a horrible horrible language.

[dargaud]

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

Re:Java, a horrible horrible language.

[ebno-10db]

There's a difference between needing an IDE and simply preferring one. With other languages I like a good IDE, but I've worked on large projects without one, and it's not terribly painful. With a Java project beyond trivial size it feels like you just can't function without an IDE. That's bad language design.

Re:Java, a horrible horrible language.

[Anonymous Coward]

More lines = more bugs, that is the simple fact.

That's why I never press enter. 1 line == less bugs, right? :-)

Re:Java, a horrible horrible language.

[delt0r]

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

Re:Java, a horrible horrible language.

[mark-t]

Swing is the most horrible toolkit I've ever tried to use

Why?

If you need an IDE, there is something wrong with your languag

And you accuse the GP of trolling? Talk about pot calling the kettle black. Although there are some cases where using an IDE is actually necessary part of using a particular programming language, Java is not one of them. For certain types of problems, many prefer using an IDE regardless of programming language... usually because the scope of the problem being solved is too large to manage efficiently with just a text editor.

Java does the opposite of trying to help you shoot yourself in the foot, by making the code bloated and spread out.

Although identifiers in Java are frequently very verbose compared to some languages, which can result in longer lines than what you'd get in terser languages such as C, for example, the actual number of LOC in my experience is roughly the same.

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!

Facebook is only one fortune 500 company and not all of them. Try checking a job board, and add up the starting salaries for jobs that use different programming languages. Java is definitely up there... jostling for position with C++, usually.

Re:Java, a horrible horrible language.

[angel'o'sphere]

Wow: Swing is the most horrible toolkit I've ever tried to use. Even monkeys can make a better one.
Then you are very lucky. I can point you to hundrets of very bad GUI libraries. Lets start with Microsofts old MFC for example.

On the other hand, I would say there are perhaps only 3 or 4 GUI libraries that are on par or better than Swing. So you must not only be very lucky but also very uneducated or you have a very strange set of "requirements" on which you judge what is good and what is bad.

But well, why do I answer to someone who did not een realize that his parent made a long joke :-/

Re:Java, a horrible horrible language.

[angel'o'sphere]

With a Java project beyond trivial size it feels like you just can't function without an IDE. That's bad language design.
That is just nonsense. If you can not program Java without an IDE, you can not program at all.

Or it applies to nearly all other languages as well, C++ ... even C, OO Pascal ... you name it.

Likely you use vim and "tags", wow, so you don't consider advanced browsing features you get from ctags etc. as an IDE?

You really WANT to program in a Notepad like editor? And if a particular language is a bit more difficult (by what rating anyway?) to program in in a "Notepad" it is a bad designed language?

Heck, I guess how the language "feels" in a "brain dead dumb" editor is very likely the lates concern a language designer has.

Re:Java, a horrible horrible language.

[TechyImmigrant]

Oh you're one of those people who doesn't know what 'your' means.

Re:Java, a horrible horrible language.

[Miamicanes]

> If you can not program Java without an IDE, you can not program at all.

It's not the language syntax per se, it's the fact that there are thousands of objects, with thousands of different constructors and methods whose syntax-consistency falls somewhere between "clusterfuck" and "bukkake" (read: Swing).

I mean, for ${deity}'s sake... we didn't even get to have a real constant representing UTF-8 Charsets until Java 7 (java.nio.charset.StandardCharsets.UTF_8) that could be used without having to explicitly try/catch for an UnsupportedEncodingException that's frankly impossible per JLS unless you used the old String-named syntax and misspelled it.

Re:Java, a horrible horrible language.

[angel'o'sphere]

Sorry, your post akes it pretty obvious that you are not an experienced programmer.

a) there are no objects ... there are classes, that is a fundamental difference
b) all classes use the same syntax for constructors, you say "syntax" but you definitely mean something different
c) talking about UTF-8, sorry I have no clue :D perhaps you are right
d) talking about Swing: I find it a very pleasant GUI library. Most people who don't like it never really used it.

Re:Java, a horrible horrible language.

[Anonymous Coward]

Complete and utter bullshit.

Java is filled with code that only exists for the compiler. It doesn't make it more maintainable or easy to read.

An example is Java's broken type system. A dozen different sort methods, that only exist to please the compiler, where in sane languages only 1 is required and it has hooks to alter the sort order or by sort by so it stays in one simple method. Add the sort by property and Java requires tons more methods and boilerplate.

Java was created for the average, poorly-educted programmer. If you are that, sure Java will look like the bees knees. But if you are even slightly more educated than the target Java market, all you see is 10,000's of lines of unnecessary code.

Why do you think crap like Spring goes through amazingly complex contortions to get around that shitty type system and all the bloat it entials?

Re:Java, a horrible horrible language.

[Anonymous Coward]

Swing is not too horrible if you use MigLayout and refuse to use inner classes of any type for listeners.

It is actually pleasant.

Sure if you use the shitty tools build into netbeans or eclipse to layout your app or use GridBagLayout life using Swing sucks.

JavaFX2 is superior to Swing, btw. As long as you don't need anything really complex.

MOST games/media apps are implemented this way...

[Dahamma]

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?

Premise is wrong

[YoungManKlaus]

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

Re:Premise is wrong

[ebno-10db]

I don't like mixed language programming myself, but you may have limited control over. it. Even if you write everything in language X, important off-the-shelf libraries and whatnot may be implemented in language Y.

Re:Premise is wrong

[serviscope_minor]

that hugely depends on your definition of "nontrivial", but generally: yes

It's easy: A true Scotsman would never write a nontrivial program in one language. You should get all your programmers from Glasgow.

Re:Premise is wrong

[serviscope_minor]

Actually just to follow up, I've had arguments with people about this before. I was arguing in favour of static linking and was eventually told by the person in question that because of the nature of libc, no nontrivial program could be statically linked because then all the fancy features were inaccessible. Ergo my program was trivial and there fore I was wasting his time to try to figure out how to statically link it.

The application was some scientific computing program which read trusted data in a simple format, did a lot of long, slow non trivial processing and wrote data in a simple format. And it needed to run on wierd-ass cluster machines with who knows what installed on them.

Long story short, a lot of people can't conceive how anything outside their area could be non trivial.

Re:Premise is wrong

[YoungManKlaus]

weeell ... I would not really consider linking a library which is precompiled and has bindings in your language (even if it is written in a different language) as "writing a program in multiple languages". You might as well argue that writing in any language that runs on a runtime is "in multiple languages" as the runtime itself is (very probably) not written in the language that it executes but rather C/C++ or something similar low-level.

Re:Premise is wrong

[ebno-10db]

You should get all your programmers from Glasgow.

Glaswegian programmers all use Haskell.

Re:Premise is wrong

[david_thornley]

There was the time back in grad school where I had to interface a Fortran linear programming package from Lisp, working on my Mac. I converted the package to compilable C using f2c, compiled the C version (probably not as optimized as it would have been with a real Fortran compiler) into a shared library, and linked it using MCL's linkage. A bit weird, but it worked with the tools I had, did not require trying to hand-translate that Fortran, and did not require changing my Lisp code to another language that would be harder to work with.

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

[fozzy1015]

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

[Anonymous Coward]

Yeah, right. End of story, eh?

Re:Sockets

[Anonymous Coward]

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

Re:Sockets

[Viol8]

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.

Re:Sockets

[jhol13]

Or considerably faster, as each process can be given own CPU.

If there is such a need to use libraries that the separation cannot be done cleanly, you might be using the languages or libraries wrong and probably get screwed.
For example I recall Java got faster unzipping after C zlib was replaced with native Java. This although it is likely that the C lib was "faster". YMMV, of course.

Personally I would always try to partition the problem into separate processes. Even if it is somewhat slower. For several reasons (architecturally better, more maintainable, easier to test, easier to understand and fix, network transparency, protection from other parts, ...).

Re:Sockets

[Shadowhawk]

Separating the libraries to run in their own process is one way to get the same effect as different libraries with some benefits (clearer boundaries of each module, the ability to switch components seamlessly, and the possibility of splitting components over difference servers come to mind).

Any socket communication using a loopback address would not be an order of magnitude slower since it never goes out over the wire. There would be some overhead (copying the data from one memory space to another), but not that huge.

Scarcity of single host applications

[Hypotensive]

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

[Anonymous Coward]

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?

Re:The real issue

[BreakBad]

Empires were built. Vote or die.

Re:The real issue

[Razalhague]

Because some syntaxes are better at expressing some concepts while others are better at expressing other concepts.

Re:The real issue

[TangoMargarine]

index, indices; matrix, matrices; syntax, syntices?

Hmm...Firefox spellcheck says no. But there are lots of things I don't trust spellcheck about.

Python fairs pretty well

[pieleric]

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.

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

[CommanderK]

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

What is wrong with plain C?

[Anonymous Coward]

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.

Re:What is wrong with plain C?

[ebno-10db]

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.

Similarly I think that these newfangled "word processors" or even text editors are ridiculous. What can't you do with pencil and paper?

I use C daily for deeply embedded stuff (no OS, ultra-low latency, etc.) and it's still the best choice for that and similar work (e.g. kernels). Sometimes I even use assembly language. But for 20 years now C has been an inappropriate language for "general purpose" applications (i.e. don't talk directly to hardware, etc.). It's too primitive and needlessly dangerous. C was originally created as a systems implementation language, and became popular for other stuff on Unix mostly because the compiler was there, and back in the day when tweaking your Unix box meant modifying the source code, everybody knew it.

Re:What is wrong with plain C?

[Anonymous Coward]

What is so dangerous about C? Programming in any language involves pitfalls. I do not know of any language that has significantly fewer 'dangers' than C. Some may make some dangers more implicit, but I do not regard that as an improvement. Generally, they just make coding more painful and coders sloppier.

I agree that C was designed for a specific purpose, but it turned out to be an excellent general purpose language for a huge number of applications. Many other languages can be used for a subset of the use cases of C, but there are very few applications of any significant size in which another language would significantly reduce code writing time, code execution time, code size or improve portability or extensibility.

Re:What is wrong with plain C?

[ebno-10db]

What is so dangerous about C?

Dereference errant or even NULL pointers, exceed array bounds, foot loose and fancy free type conversions, I'm sure you've heard these and more. If you really like to write code without the safety net, use assembly language (I sometimes do). As for making "coders sloppier", I find that's true of all these newfangled HLL's. I'm never more careful or more disciplined than when writing assembler.

I know how to avoid the dangers of C, and dare say I'm pretty good at it. I rarely make a mistake, but rarely isn't never. Also sometimes I work with other programmers that frankly aren't as good at avoiding the dangers. Makes integration fun. The situation is even more fun when security is a major concern (it generally isn't for what I do).

Some may make some dangers more implicit

What does that mean and what's an example? No snark - I honestly don't understand the point.

Use an Enterprise Bus

[Anonymous Coward]

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

Leave windows behind please.

[upuv]

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.

Re:Leave windows behind please.

[Megane]

.NET is an abomination of performance and security disasters.

As clearly evidenced by a .NET patch being in almost every Patch Tuesday. Times three (1.x 2.x 4.x version all get patches most of the time). And the .NET installers are noticeably slower than most installers. Pay attention to what Windows Update is installing and you'll wonder how a programming language runtime could have so many bugs.

Re:Leave windows behind please.

[RabidReindeer]

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 of work to set up. But the primary employment for Java these days is in servers where the VM startup occurs maybe once a day or less and the initial massive performance hit is more than compensated for over the productive run time of the VM.

Re:Leave windows behind please.

[Anonymous Coward]

Um, based on this post I'm not sure that you know what .NET is, particularly with the claim that RMI is part of its founding principals. Most .NET apps make zero use of any of the available RMI labs. You could just as easily claim that Java sucks ass because there are CORBA libs.

Re:Leave windows behind please.

[upuv]

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 nightmare. Good Java dev's can make it perform very well. But guess what. There not not many of them at all. My simple test is this. When I saw take that JVM that is sitting on a 8Gig heap and knock it back to 2Gig to improve performance and the dev goes "What!!!!!! are you insane." I know the dev most likely knows nothing about performance of Java.

Don't even try to tell me that SOA is a performant way to build distributed architecture systems in Java. XML serialization and de-serialization is a performance disaster. Even the code libraries SUCK. The concept of a GC was great when it first came out. But this is in the days when a Meg was a massive amount of memory. Now we are looking at Gigs to 100's of Gig's of in memory objects. GC just can not cope with this. So you have to start developing models that involve lot of distinct processes to handle the memory and compute footprint. No longer can you fit every thing into one memory space. Languages like Java accelerate this evolution by the simply being horrendous consumers of RAM. ( At this point some one should be barking about pauseless GC in products like Azul. ) Not really seeing this gain traction. Why? Because guess what java is still a horrendous compute beast. With most use cases not matching the profile for things like Azul. Azul excels in really large in memory data stores but relatively low numbers of processing threads across that store. AKA not well suited for web and high transaction envs. What does work really well for large datasets and huge amounts of concurrency in Java is things like TerraCotta with it's off heap memory manager and distributed eventually consistent cache. But this is a pricey option.

I'm going to toss out a troll word here. "Websphere". ( Watch as Jave devs shrink into the shadows at the mention of that word. )

The JVM does do some tuning at run time. Granted. But it's only a bandaid and not a very good one, because it just can't keep up to the volume of simply horrible code being pumped out by very low grade java devs.

But it's still better than the situation of the windows platform in the data center. WOW. Windows in the server room just makes me go grey. 2/3 of my performance engineering gigs are for wintel. Magical bandaids are what the customer wants. Rarely can we provide. The ones that are serious always go for re platforming to linux.

Re:Leave windows behind please.

[RabidReindeer]

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

No, Java is not perfect. But it can be very effective when not wielded by clueless monkeys. The real problem isn't the language, it's the business attitude that all you need to develop complex systems is a handful of cheap monkeys.

Re:Leave windows behind please.

[BreakBad]

This

Re:Leave windows behind please.

[Rockoon]

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

Interesting that you ignored this logic when you so quickly pointed out that "Modern JVMs often out-perform even assembly language due to their ability to..."

The fact is that "modern JVM's" continue to prevent serious attempts at approaching optimality, just like their ancestors. Full stop. You dont get to have it both ways, so stop pretending that you can.

Re:Leave windows behind please.

[Anonymous Coward]

Modern JVMs often out-perform even assembly language due to their ability to analyse and tune for the actual operating environment.

In general I agree with you, Modern JVM is very good in regard to optimization. Dynamic optimization is excellent.

However, it's ignorant to say that JVM "out perform" assembly language. The JVM still compiles to machine code to execute on the CPU. It does not compile down to magical fairy dust that is somehow faster than the x86-64 code or whatever you happen to be running.

For a given input (note, this is a huge caveat) it is quite possible to hand write assembly language that is faster than the JVM. In fact, you could simply take the final output of the JVM after all the hotspot optimizations, and make one optimization and bam - you've beaten it using an assembler.

For compilers, such as C, there is also such a thing as a profile guided optimization. You run the program with profiling, feed the profile data back into the compiler, and it can make those same optimizations as Java. This will be quite effective as detecting "hot spots" in your code and optimizing them with, for example, more aggressive loop unrolling.

Now a dynamic adaptive compiler (which is what the HotSpot JVM is), will be able to produce better code than a profile guided optimizing compiler for widely different execution paths IF the program runs long enough to allow such optimizations to be effective. If consecutive runs of your application have the same hotspots, however, a PGO compiler can beat it and will have no warm up time to boot.

Which brings up another exception to your blanket statement: Programs which do not execute for long periods of time (say, less than the 10,000 iterations typically required to trigger native compilation in a HotSpot VM) can potentially run faster then the tiered compilation of the JVM as it is not so aggressive on the optimizations for the JIT phases.

Finally, not all JVMs are as good as the HotSpot JVM. For example, I the Dalvik VM on a phone does JIT compilation, so a good optimization C compiler (or hand written assembly code) would have a chance to beat it.

So in short, your blanket statement is true in some edge cases and for certain types of applications (i.e., applications that run long enough for the "warm up" to be justified, with widely divergent "hot spots" between different runs) but it's completely false to say that in the general case "JVMs out-perform assembly language." It just sounds ignorant and makes it seem like you don't understand that "assembly language" (or more precisely, machine code) is what the JVM produces. Not fairy dust.

Re:Leave windows behind please.

[RabidReindeer]

Non sequitur.

The performance of the language environment has absolutely nothing to do with the competence of the programmers beyond the fact that good programmers can bring out the best in a platform while bad programmers can bring out the worst.

I've seen some real abominations committed in assembly language as well. Heard whole teams scream in horror about the techniques employed by one of their allegedly experienced C programmers. Had to deal with code that actually broke COBOL compilers.

I don't believe in a "both ways" oriented world. Leave that to the Republicans and the Democrats. There are rarely only 2 sides to an issue. There are things done well one way and things done well another and still other things better done a third way. What I am saying is that there are hard numbers published on JVM performance and they disagree with what most java-bashers "know". High-performance JVMs can optimize low-level execution better than fixed-code generators simply because they can measure and re-code dynamically based on what the program flow is and not on what the programmer "knew" it would be back when the program was compiled/assembled.

But low-level optimization isn't the only thing. Pick the wrong algorithm for the task and no amount of instruction-level tuning may be able to beat code in even the least-optimized of languages using a more appropriate algorithm.

Re:Leave windows behind please.

[Rockoon]

The performance of the language environment has absolutely nothing to do with the competence of the programmers

...which has fuck-all to do with your first post.

You cannot save your argument about "Modern JVMs often out-perform even assembly language due to their ability to analyse [SIC] and tune for the actual operating environment" by inventing a new argument.

Your have crossed over into bull-blown intentional dishonesty.

Re: VHDL? this kind of comment system is dead

[Anonymous Coward]

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

The ultimate in cross-language interoperability

[Megane]

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

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

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

Language workbenches enable cross-language interop

[FabienCampagne]

It it surprising to me that the article makes no mention of language workbenches, when they are a good solution to the problem the article describes. See our preprint https://peerj.com/preprints/112v2/ for an example of language interoperability, and references therein for descriptions of language workbenches.

Language wars.

[leuk_he]

Oh no...
xxxx is better than yyyy because..

Langugages (and really the platform / libraries are more important) ech have their own strength.

What you don't want to do is to solve a problem, add a prgramming language, because then suddenly tou have 3 problems instead of one:
-being to able to write in 2 langugages. (the subset of emplyess able to do that is much much smaller than those having good skills in one languges
-interface between them (rarely done, so few people understand the details.
-maintaining for a long time mulple languages.

If you run a JAVA enterpise. Fine. If you run perl/php, Fine. If you run C? ueh....cobol? Keep it!

Been there, doing that

[lwriemen]

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.

Re:Been there, doing that

[phantomfive]

Wow, you're the first person I've ever met who actually uses that kind of system. Thanks for the info.

Re: VHDL? this kind of comment system is dead

[ebno-10db]

Verilog won the popularity contest

Does that make it a better language?

Also VHDL is still quite popular some places. I've worked for several companies in the last 10-15 years that use it. I suspect VHDL and Verilog will continue to co-exist. As far as tool chains are concerned, they're both essentially front ends. It's not hard to support both, and most do.

Non-trivial was always cross-language

[Fringe]

I get annoyed when the premise is so flawed, but stated as fact.

Major projects have been cross-language for decades. In the 70s, Fortran + C + Assembly were in most big languages. Or large systems using COBOL having to interface to non-COBOL systems. By the 80s, many had bits of Pascal (Borland was huge, remember?) and BASIC, with important routines hand-optimized in assembly. Or C. By the 90s, we had SQL and native code, DLLs written in random languages, and often VB for the UI. Most of what you use on a daily basis probably is browser-hosted but includes active controls in C# or C++, back end code in PHP or Java, database code in SQL and browser code in JavaScript or ActionScript. Many of my Android apps are mostly Java with some kernel-level support in C.

Yes, each language has it's own way... COM, exports, dllimport, etc. Until it has one, it's not a very functional language. But this isn't a new development.

Re:Non-trivial was always cross-language

[mjwalshe]

Yep I worked for BT we ran the Biggest IBM based system in the world - they still used IBM assembler when they wanted performance.

Score one for Fortran

[Anonymous Coward]

Sheesh, even modern Fortran compilers can be interfaced directly with C code (use ISO_C_BINDING) — I do it all the time with gfortran. If even Fortran can get it right, surely the Java folks can agree on a standard way to get this done!

Learn from Apple.

[guignome]

The success of Android (Java) and iOS (Objective-C) showed us that allowing several languages on a platform just adds unnecessary complexity. One language is sufficient to develop great applications.

Re:Learn from Apple.

[kthreadd]

Well, Objective-C is C, and it can even be mixed easily with C++. Not to mention that there's a lot of people using C# (Mono) on iOS.

IBM ILE

[wcrowe]

IBM solved this problem 20 years ago with their Integrated Language Environment (ILE), not that anyone cares.

(Damn noobs think every problem they encounter is new and unique).

True Scotsman

[handy_vandal]

Instead of getting my programmers from Glasgow, I am sending my current programmers -- broke, penniless, desperate -- to live on the streets of Glasgow for a year.

Those that survive the ordeal will return to my Xanadu-like pleasure palace, where they will serve out their remaining years in matchless luxury.

Yeah, but Java is slow (if _I_ write it)

[Theovon]

Paul Graham liked to blog about how awesome Lisp is. Apparently, he did some web back-ends in Lisp and was able to stay ahead of the competition. Now, Lisp has some awesome features. The two that stick out to me are (a) Lisp macros, which are arbitrary Lisp code run at compile time that emits arbitrary Lisp code that gets compiled, allowing some seriouly powerful constructs to be created very concisely and (b) massive libraries. That being said, I suspect that Paul Graham and his cohorts were more successful at using Lisp compared to another back-end language because they were both very skilled at the language and also super smart. The language they chose is actually MUCH less important. If they’d chosen another language, they would have done probably just about as well.

If you’re not a super smart programmer, I recommend Java (among other languages). Pass-by-reference and garbage collection obviate a lot of coding mistakes. And with Jit compilation, you get pretty darn fast code. Under 99% of circumstances Java performance is way better than adequate and makes MUCH better use of programmer engineering time.

But if what you want is super fast performance, a super smart C++ programmer will beat a super smart Java programmer. It’s a lot HARDER to get better results from C++, but the ceiling is higher. Some reasons for this:

- In memory-constrained environments, garbage collection imposes some overhead. I’ve worked on huge programs near the VM size limit whose performance was limited by GC performance. Most of the time, incremental GC in another thread is a win, but it can be a huge liability in memory constrainted environments. Instead, manual memory management in C++ allows you to make tighter use of the memory space and performs better in a memory-constranied environment.
- In a CPU-constrained environment, background GC steals cycles away from computation.
- Just like how macros are a huge win in Lisp, C++ templates generate customized code at compile time that can have huge perfrormance benefits. This is why C++ sort is faster than the C library qsort: The C++ sort is a template that inlines the comparison function for the type you’re sorting, rather than making a method call. In Java, you MIGHT get some of this from a fabulous JIT compiler.
- Compiling to bytecode is a huge information loss. If you used gcj to compile Java to native code, there’s the potential to have less information loss and therefore optimize better based on the programmer intent. But normally, Java uses bytecode as an intermediate. With more programmer intent knowledge, the C++ compiler can make smarter optimizations.

I could add more things, but I have other real work to do. Before I go, I’ll cap this off with two practical thoughts. You CAN get better performance from C++ than Java. Do you WANT to?

- Java has massive libraries too, where the critical parts are written in optimized native code, so if you make heavy use of Java libraries, you’ll see almost no difference in performance with regard to CPU throughput (GC being a separate issue). With no perceptible impact on peformance, less code to write, fewer common programming errors, and better use of engineering time, Java is quite often just an all-around practical win over C++. I say this as a programmer who prefers C++.
- If you’re REALLY REALLY concerned about performance, use Fortran. The language is more restrictive, providing the compiler with even more freedom to optimize. (For instance, no aliasing, no recursion.)

OMG CORBA

[cabazorro]

OMG tried to tackle the language interoperability with CORBA ( Common Object Request Broker Arch ).
They created another language: IDL
wait.

Use AMQP or ZeroMQ

[Anonymous Coward]

I like to use message queuing technologies like AMQP or ZeroMQ to achieve this kind of integration. Much simpler than link editing everything into one monstrous binary artifact.

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

[Dahamma]

Yeah, there are a bunch of games/engines that use Lua for their scripting now (and others that use Javascript, and some that implemented their own language, eg. QuakeC).

Not sure why my original post was labeled "flamebait". I guess someone out there in "CS academia" had mod points :) (it was a joke, people!)

The most successful place this exists today

[snadrus]

On the web we have tens of languages on the server side communicating to browsers & crawlers. Crawlers are written in nearly every language.

How did we do it? A standard protocol.

So, stand up 2 programs, have a standard for message passing, and continue working. Forget library-like integration: you don't want some giant code in your process space anyway.

- Testing is simpler.
- Fractional deployment is equal to having DLLs, but simpler resource file management.
- Crashes are easier to debug, and far less insulation is necessary for a good overall experience.
- Scalability becomes simpler.
- The initiator of an internal issue can be hard to determine, but many solutions exist & it's often unnecessary to know.

Summary: Do one thing, do it well

Re: VHDL? this kind of comment system is dead

[TechyImmigrant]

Verilog won the popularity contest

Does that make it a better language?

Also VHDL is still quite popular some places. I've worked for several companies in the last 10-15 years that use it. I suspect VHDL and Verilog will continue to co-exist. As far as tool chains are concerned, they're both essentially front ends. It's not hard to support both, and most do.

As far as I can tell, SystemVerilog won the popularity contest. This imports a number of VHDL ideas into verilog that make life easier. What it fails to do is import the operator overloading and resolution functions that works so effectively in VHDL. In VHDL if you want to define a new logic value, like say 'P' for values driven from unpowered logic, you can simply overload the std_logic operators, or replace std_logic, and the simulator will work for you. No so in Verilog. The logic values (1, 0, H, L, X etc) are wired into the language. You can't add a 'P'. Consequently, SystemVerilog makes it really difficult to verify low power fine-grained power gated designs.

Of course nobody making tool purchasing decisions considers these things.

isn't this what services are for?

[PJ6]

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

I'm under the impression that this one of the primary use cases of service-oriented architecture.