Ask HN: Why aren’t libraries inter-callable by default? | Hacker News Reader

Ask HN: Why aren’t libraries inter-callable by default?

14 pointsabrax31417 comments

Lisp is dead. Really dead this time. But it’s not bcs of the language, it’s bcs the libraries haven’t kept pace with, say, Python. But wouldn’t it be easy to write an “interface matcher” that would easily allow Lisp to call python libraries. (Obviously, replace Lisp and Pyhton with L1 and L2 - in fact you don’t even need L2 bcs all libraries could in theory be written to this FFAPI, so to speak, and then any language could call on all the best libraries and people could stop wasting time replicating libraries in every L1!?)

View on HN

clojure now reaches jvm, js, a stored procedure language inside a database, (apparently also CLR but i haven’t tried it) and you can target them all with the same portable code, and they have a compatible value interchange format (like JSON) which reaches many more foreign platforms. our prod codebase at http://hyperfiddle.net is portable clojure and runs on all above listed platforms, with seamless foreign interop for any native functionality, we have dozens of NPM dependencies for our browser client (seamless enough interop that we actually prefer npm libs over clojurescript libs as they tend to be more mature)

the main thing is the data structures need to be compatible, any value you have on one platform needs to be instantiable on all the others, that is the only way to have the libraries call into each other without impedance. the value notation is called EDN and the value interchange mechanic (that manufactures platform specific value instances) is called Transit.

Clojure has a pretty cool network effect if you ask me

Ah, so if we all agreed that the jvm is the clr of the posix world, and then programmed in jython and clojure (or ABCL), and other j-* languages that sit on the jvm, then, modulo struct wrangling, this is what I’m after.

not quite. there are two types of foreign interop - large scale and small - both matter. 1/ for distributed system interop, i think the struct wrangling can be solved at the transit layer - transit reaches cpython. for local interop, Clojure doesn’t reach C yet but there is at least one attempt to get it there on top of google right now. i see a clear consolidation loop.

what is important in the big picture is that the semantics of the values are the same everywhere, not necessarily that they are memory compatible.

Some people use protobufs to achieve a setup sorta like what you described. They work well if you have common REST objects but want to write microservices in multiple languages.

Coconut (https://github.com/evhub/coconut) might be interesting to you too.

Hylang and Pymacs call python functions from lisp.

As I understand them, this isn't quite what I'm after. These are Lisps implemented in Python (at least Hy is -- I'm not familiar with Pymacs). I'm not fixated on Lisp, and just implementing an L1 (L1=Lisp for the sake of the example) interpreter on L2 doesn't seem to be what I'm after. I want to be able to use whatever language (L1) I like (within reason), and be able to call out to packages that happen to be written in whatever language (L2) the package authors preferred. Obviously you need to have the L2 runtime available, which is presumably how CLR (and JVM in the hypothetical above) sort of do this -- everyone runs on a common runtime, sort of like everyone use to compile to the metal so that (modulo struct wrangling) it didn't matter what L2 was bcs at the end of the day everyone talked machine language. The stupid obvious way to do this is, of course, just RPC where you call out to a python (or whatever) server, and this is what I actually do now, but the overhead of communications is ugly if not slow, and there's all sorts of issues with debugging etc.

Microsoft’s .NET languages and the CLR do this. You can even use IronScheme so you’ll have a Lisp with a ton of libraries.

Reply on news.ycombinator.com