
Ask HN: Why aren’t libraries inter-callable by default? - abrax3141
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!?)
======
dustingetz
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](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

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

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

------
tedmiston
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](https://github.com/evhub/coconut))
might be interesting to you too.

------
j88439h84
Hylang and Pymacs call python functions from lisp.

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

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

