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!?)
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 <a href="http://hyperfiddle.net" rel="nofollow">http://hyperfiddle.net</a> 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)<p>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.<p>Clojure has a pretty cool network effect if you ask me
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.<p>Coconut (<a href="https://github.com/evhub/coconut" rel="nofollow">https://github.com/evhub/coconut</a>) might be interesting to you too.