July/August 2018 issue of acmqueue The July/August issue of acmqueue is out now
Subscribers and ACM Professional members login here

Programming Languages

  Download PDF version of this article PDF

Error 526 Ray ID: 46ddf01308e791ac • 2018-10-22 18:13:25 UTC

Invalid SSL certificate








What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.


Originally published in Queue vol. 11, no. 10
see this item in the ACM Digital Library



David Chisnall - C Is Not a Low-level Language
Your computer is not a fast PDP-11.

Tobias Lauinger, Abdelberi Chaabane, Christo Wilson - Thou Shalt Not Depend on Me
A look at JavaScript libraries in the wild

Robert C. Seacord - Uninitialized Reads
Understanding the proposed revisions to the C language

Carlos Baquero, Nuno Preguiça - Why Logical Clocks are Easy
Sometimes all you need is the right language.


(newest first)

Walter Falby | Wed, 18 Dec 2013 15:20:07 UTC

I read this article in the Communications of the ACM (CACM). The subtitle caught my attention: Interfacing between languages is becoming more important. Once I got into the article, it's not about language interfaces but about some notion of interoperability. Language interfacing is a decades old problem that has been solved mainly by passing data - output of one program is input to another. Enabling languages such as COBOL, variants of C and assembler to access Java functionality can be done via a bridge that's built once and used by many. There are various techniques for handling parallelism for code that benefits from that execution model. So what problems does this article address that aren't being solved today by other methods? This is an important question as the article was in the Practice section of the CACM. Discussions on how current approaches perform must be instance-specific. The implementation may be the problem, not the approach. Am I being too practical or limited in my thinking? Are there other issues that current approaches to interfacing languages don't solve? Issues such as memory models, garbage collection and exception handling come about because of the interoperability notion. If we state that the problem is to use the appropriate language for each part of a particular system, then why are current language interface methods not sufficient?

David Piepgrass | Thu, 05 Dec 2013 01:11:36 UTC

This article expresses merely the start of the problems. In any real application you need not just call functions, but also pass data between different languages. A common representation for strings, arrays, linked lists, hashtables, and other data is therefore warranted.

While VMs are not a panacea, I'd hardly use the term "VM DELUSION". The Java VM was not designed to be a multi-language solution, and although the .NET Framework was specifically designed for multiple languages, there are numerous problems its design did not address; consequently .NET cannot fully support new languages such as D and Go, and the integration of C++ with .NET is ugly; the "managed" and "unmanaged" parts of C++/CLI are substantially different languages, silos that are inconsistent with each other, that interoperate clumsily.

So while VMs haven't been great at interoperability so far, I think that's because they simply weren't designed well enough. I would personally LOVE to work on a better VM that acts like a superset of JVM and CLR, that supports a broader class of statically-typed languages. I just don't know of any company or research group with this goal ( but see my related project, http://loyc.net ). In fact I think a VM like this should eventually replace Javascript for web development and I wish Google or Mozilla would launch such a project. Native code, with its tendency to segfault, is less than ideal for web development; Google's NaCl can run native code more safely, but it offers no cross-language interoperability, and it is a barren platform with minimal built-in facilities, so web sites may have to transmit large binary code libraries to clients rather than rather than relying on built-in facilities, as they could with Javascript.

That said, we also need an interop platform that is not VM-based.

@C. Thomas. Huh? C is a really, really lousy basis for interoperability. It is necessary to provide C interoperability in practice, but it's crazy to imply it's a solution to all interoperability woes. In C there's no universal standard for memory management, certainly no possibility of precise garbage collection, no standards to guarantee memory safety across languages, no exception support, no standard for reflection or interfaces or discriminated unions, the list goes on and on. C interop is a starting point, not a destination.

C. Thomas Stover | Wed, 04 Dec 2013 23:15:30 UTC

While your observations are well stated and correct, the conclusion you actually are making an excellent case for, is the one you are arguing against. That is, C remains the single best inter-language glue. A more practical wish, would be for the truly crusty corners of software engineering that still have no interoperability with C to get fixed. In the work of many, including my own, C is not used for any of its classically accepted strengths, but instead for explicitly leveraging it's interoperability qualities. The more glaringly obvious this reality continuos to be, the more vehemently it is dismissed as impractical.

Ben Liblit | Wed, 04 Dec 2013 19:51:17 UTC

Hmm, removal of anything vaguely HTML-like was even more aggressive than I expected. Once again, this time with useful URLs:

"Automatic Generation of Library Bindings Using Static Analysis" http://pages.cs.wisc.edu/~liblit/pldi-2009-b/

"Analyzing Memory Ownership Patterns in C Libraries" http://pages.cs.wisc.edu/~liblit/ismm-2013/

Ben Liblit | Wed, 04 Dec 2013 19:49:53 UTC

As long as we are each expressing surprise that our own efforts in this area were not mentioned, here are mine:

"Automatic Generation of Library Bindings Using Static Analysis"

"Analyzing Memory Ownership Patterns in C Libraries"

Tom Epperly | Wed, 04 Dec 2013 16:19:58 UTC

It's also surprising that the manuscript makes no mention of Babel, a tool that addresses many of the concerns raised for a wide selection of languages. http://computation.llnl.gov/casc/components/

Lee Riemenschneider | Wed, 04 Dec 2013 13:20:35 UTC

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. Currently model compilers exist for C, C++, Java, Ada, System C, and I'm sure there's more that I haven't encountered.

Fabien Campagne | Wed, 04 Dec 2013 13:00:11 UTC

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

Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.