... but we have temporarily restricted your access to the Digital Library. Your activity appears to be coming from some type of automated process. To ensure the availability of the Digital Library we can not allow these types of requests to continue. The restriction will be removed automatically once this activity stops.
I got that too, despite being already logged in to the site. I clicked on the PDF logo in the upper right corner, though, and was served the paper. Some bug, I guess.
A lot of this has to do with languages in no way designed for interoperability. There have been platforms designed for cross-language development.
OpenVMS standardized calling conventions for interoperability. CLR does that at a VM level in low-level way. Ten15 on FLEX machine did it in high-level way. Lots of variants of languages are targeting C, JVM, etc structured in ways that make interoperability easier. Julia making using C and Python code easy is an example. Finally, there's metaprogramming tools that make all the languages DSL's interoperable via core language. Racket, Alan Kay's stuff, and sklogic's tool cone to mind.
The ones having trouble are usually evolved away from cross-language development with a lot of complexity that makes it harder than it already is. Of course they're having to resort to things like ZeroMQ or whatever.
I'm on the lookout for a language that does a) not itself require a VM (can be properly compiled) or significant runtime, but b) can be hosted in a VM without too many leaky abstractions, and c) can interface well with other ABIs and VMs.
C++ comes close (e.g. with Windows Runtime and Objective-C++) but its memory model fails (b) and there are no type generators or such so you get a lot of glue code generation.
A small Lisp dialect could easily be hosted in any VM and it can be made to interface well with just about anything transparently (look at Racket's C bindings) but the dialects I've seen fail (a) and lack lifecycle hooks that would make building a C++0-like com_ptr<> type possible.
I originally wrote a long reply, but my damn tablet crapped out on me and I lost it, so my apologies for the brevity here.
Object Pascal will do most of what you want ( c) with VM interop is an issue, but will be for most languages), and is available on a lot of platforms.
On native platforms, you get straight-up manual memory management of class instances (Create/Free methods) or alloc/free memory directly.
On VM platforms like the JVM or CLR, or LLVM-backend compilers that use ARC, the Create/Free methods for class instances are typically mapped to Create/Dispose methods so that non-GCed resources can be disposed of properly.
Things like strings, dynamic arrays, and interfaces are already reference-counted and don't use manual memory management, but can be move'd, etc. and dealt with like normal blocks of memory on native platforms.
There is also marshalling for lower-level access to C APIs from the VM platforms and LLVM back-ends, and direct call access to C APIs from native code with various call modifiers.
There are also some neat things for native platforms like methods for hooking class instance allocation so that you can provide your own per-class memory pools.
The only downside is that you may find some syntax differences on certain platforms, and besides Free Pascal, the compilers tend to cost $$$.
There's no standardisation of how to represent ownership across ABI boundaries yet, and different languages' models are fundamentally incompatible: either the VM/runtime expects to own all memory management (in which case interfacing with another VM/runtime that follows the same model is virtually impossible) or the programmer does it manually (perhaps with some help from the language in the case of C++ or Rust). Embedding a language that does the latter in a VM language is always going to involve fiddling with memory ownership in a language unsuited to it (as you do when using SWIG or the like).
What are you actually trying to achieve here? If you're writing a library for use from both VM and non-VM languages, you'll want your library functions to have clear/simple memory ownership semantics anyway, and at that point any unmanaged language will work reasonably well for you. If you just want your library to be usable from several different styles of language, maybe a multi-language VM will work for you.
You seem to be asking for contradictory things. For instance, low runtime overhead implies manual memory management but running within a VM implies automatic memory management. What about a "bundled" runtime like Go, some Lisps, or Ocaml? Lua?
Your c) needs refinement. It's not just memory ownership but also idiomatic use of the language. Heavy on objects? Functions? Mutable or immutable (don't forget strings)?
[+] [-] egypturnash|7 years ago|reply
... but we have temporarily restricted your access to the Digital Library. Your activity appears to be coming from some type of automated process. To ensure the availability of the Digital Library we can not allow these types of requests to continue. The restriction will be removed automatically once this activity stops.
We apologize for this inconvenience.”
Anyone else getting this?
If so, have a Wayback Machine link: http://web.archive.org/web/20180219210654/https://queue.acm....
[+] [-] ScottBurson|7 years ago|reply
[+] [-] squeaky-clean|7 years ago|reply
[+] [-] gizmo686|7 years ago|reply
[+] [-] nickpsecurity|7 years ago|reply
OpenVMS standardized calling conventions for interoperability. CLR does that at a VM level in low-level way. Ten15 on FLEX machine did it in high-level way. Lots of variants of languages are targeting C, JVM, etc structured in ways that make interoperability easier. Julia making using C and Python code easy is an example. Finally, there's metaprogramming tools that make all the languages DSL's interoperable via core language. Racket, Alan Kay's stuff, and sklogic's tool cone to mind.
The ones having trouble are usually evolved away from cross-language development with a lot of complexity that makes it harder than it already is. Of course they're having to resort to things like ZeroMQ or whatever.
[+] [-] sjmulder|7 years ago|reply
C++ comes close (e.g. with Windows Runtime and Objective-C++) but its memory model fails (b) and there are no type generators or such so you get a lot of glue code generation.
A small Lisp dialect could easily be hosted in any VM and it can be made to interface well with just about anything transparently (look at Racket's C bindings) but the dialects I've seen fail (a) and lack lifecycle hooks that would make building a C++0-like com_ptr<> type possible.
[+] [-] TimJYoung|7 years ago|reply
Object Pascal will do most of what you want ( c) with VM interop is an issue, but will be for most languages), and is available on a lot of platforms.
On native platforms, you get straight-up manual memory management of class instances (Create/Free methods) or alloc/free memory directly.
On VM platforms like the JVM or CLR, or LLVM-backend compilers that use ARC, the Create/Free methods for class instances are typically mapped to Create/Dispose methods so that non-GCed resources can be disposed of properly.
Things like strings, dynamic arrays, and interfaces are already reference-counted and don't use manual memory management, but can be move'd, etc. and dealt with like normal blocks of memory on native platforms.
There is also marshalling for lower-level access to C APIs from the VM platforms and LLVM back-ends, and direct call access to C APIs from native code with various call modifiers.
There are also some neat things for native platforms like methods for hooking class instance allocation so that you can provide your own per-class memory pools.
The only downside is that you may find some syntax differences on certain platforms, and besides Free Pascal, the compilers tend to cost $$$.
[+] [-] lmm|7 years ago|reply
What are you actually trying to achieve here? If you're writing a library for use from both VM and non-VM languages, you'll want your library functions to have clear/simple memory ownership semantics anyway, and at that point any unmanaged language will work reasonably well for you. If you just want your library to be usable from several different styles of language, maybe a multi-language VM will work for you.
[+] [-] Steltek|7 years ago|reply
Your c) needs refinement. It's not just memory ownership but also idiomatic use of the language. Heavy on objects? Functions? Mutable or immutable (don't forget strings)?
[+] [-] _pmf_|7 years ago|reply
[+] [-] merb|7 years ago|reply