
Too Many Programming Languages - supster
http://sapan.svbtle.com/dealing-with-a-plethora-of-programming-languages
======
Nadya
>Then we could all write in our favorite languages and make sure the code is
transplied to Lisp - just a thought.

I read this as:

"There are too many programming languages. Why can't everyone just use Lisp?"

I laughed a little to myself due to the Lisp user stereotype of parading Lisp
around as every programmer's savior. Did it come off that way to anyone else?
I don't mean to offend, as I rather enjoy Lisp too. But I felt the premise of
the article was "all code should transpile to other code" and I ended up
reading it as "all code should be Lisp".

Maybe that was the intended humor. Maybe humor wasn't intended. Either way, I
got a laugh out of it.

There are a ton of libraries/wrappers use to run X code in Y language or
middle-men. Rubypython [一] comes to mind. While it doesn't fully cover the
problem it's a start. However is that method the one we want to use? Does a
better method even exist or is a better method even possible?

[一] [http://rubypython.rubyforge.org/](http://rubypython.rubyforge.org/)

~~~
supster
Lol, OP here, I guess in an indirect way that's how it came off. I don't
really think everyone should write in Lisp, but rather that we all should be
able to write interoperable code, and one suggested solution is a tree like
structure - which happens to be Lisp. Maybe a Unix pipe type construct would
be better? Just some thoughts on a lazy Thursday afternoon.

------
nostrademons
This doesn't work because there are a number of semantic distinctions layered
even on top of Lisp-like syntax tree, and all those languages have different
semantics. Common Lisp, Scheme, Clojure, and Arc are all Lisps, but you can't
use code written in one of them inside a different one.

The way you get language interoperability is to define a common data format
and a common way of indicating which code will execute next. A number of
standards do this - platform ABIs, C calling conventions, LLVM/JVM/.NET
bitcode, RPC frameworks like gRPC/Thrift/CapnProto/MessagePack/JSON-RPC/Avro -
but they're all lower level than you would normally want to program in.

------
c-rack
Projects like zproto [1], by using the "Universal Code Generator" GSL [2],
have maybe already found the "common denominator" you are looking for.

[1] [https://github.com/zeromq/zproto](https://github.com/zeromq/zproto)

[2] [https://github.com/imatix/gsl](https://github.com/imatix/gsl)

------
mlanza
I suggested something similar to this a while back:
[http://www.halfbakery.com/idea/Tech_20Spec_20Plugins](http://www.halfbakery.com/idea/Tech_20Spec_20Plugins)

------
ingenter
Here's a crazy thought: we already have a common denominator -- IPC.

You _can_ write part of your program in Java and other part of it in Python.
But the cost of transmitting messages is considered too high most of the time.

