The Language-Language Matrix(langlangmatrix.com)
langlangmatrix.com
The Language-Language Matrix
http://langlangmatrix.com/?
21 comments
What we see in Clojure (like other Lisps) is minimal syntax directed at the idea of homoiconicity. This means that the program's structure is similar to its syntax. It also means that we can represent the program as a data structure in the language itself.
So (1) Simple syntax, and (2) being able to represent the program structure in the language easily, both lead to making it easy to build compilers, interpreters and bytecode compilers. The barrier to entry for these tasks is lower in Clojure.
Many would also say that (1) and (2) make Clojure a joy to program in, but I'll leave that to the reader to judge for themselves.
So (1) Simple syntax, and (2) being able to represent the program structure in the language easily, both lead to making it easy to build compilers, interpreters and bytecode compilers. The barrier to entry for these tasks is lower in Clojure.
Many would also say that (1) and (2) make Clojure a joy to program in, but I'll leave that to the reader to judge for themselves.
> Many would also say that (1) and (2) make Clojure a joy to program in, ...
Yep, the opposing view being that the lack of syntax that some see as a benefit actually makes it inexpressive, compared to a language with more syntax that expresses its ideas more like human language (e.g. Ruby, Python).
> but I'll leave that to the reader to judge for themselves.
Same! Not made my mind up yet, currently struggling through the Clojure book.
Yep, the opposing view being that the lack of syntax that some see as a benefit actually makes it inexpressive, compared to a language with more syntax that expresses its ideas more like human language (e.g. Ruby, Python).
> but I'll leave that to the reader to judge for themselves.
Same! Not made my mind up yet, currently struggling through the Clojure book.
I recently came across this new Clojure book:
http://www.braveclojure.com/
Seems like potentially an accessible and entertaining intro to the language. Perhaps it could be a good way to get your feet wet before diving into one of the larger tomes.
http://www.braveclojure.com/
Seems like potentially an accessible and entertaining intro to the language. Perhaps it could be a good way to get your feet wet before diving into one of the larger tomes.
Thanks!
Clojure is designed as a hosted languages from the start and intentionally exposes platform semantics for many operations, such as math, strings, etc. This makes porting easier, since one doesn't have to implement "compatibility layer" for all those operations.
On a side note, Clojure concurrency primitives implement different ideas compared to FRP. A good source to learn about ideas behind Clojure concurrency is this talk by Rich Hickey: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... . At 1:08:25 Rich tells his opinion about FRP.
On a side note, Clojure concurrency primitives implement different ideas compared to FRP. A good source to learn about ideas behind Clojure concurrency is this talk by Rich Hickey: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... . At 1:08:25 Rich tells his opinion about FRP.
I haven't watched that part of the video yet, but I've always believed that Rich's biggest blind-spot seems to be about not realizing how Clojure's macro system can be used to rewrite regular code into FRP.
Just have a look at what a macro like Javelin [1] already enables [2] and imagine how powerful that would be when combined with 'live' Datolog queries where the query results in the browser will stay up to date with the results from the logic datalog query on Datomic.
I've tried explaining it to Rich at EuroClojure 2012 but I'm pretty sure he was still thinking in terms of 'classic FRP' back then.
[1] https://github.com/tailrecursion/javelin [2] http://www.infoq.com/presentations/ClojureScript-Javelin
Just have a look at what a macro like Javelin [1] already enables [2] and imagine how powerful that would be when combined with 'live' Datolog queries where the query results in the browser will stay up to date with the results from the logic datalog query on Datomic.
I've tried explaining it to Rich at EuroClojure 2012 but I'm pretty sure he was still thinking in terms of 'classic FRP' back then.
[1] https://github.com/tailrecursion/javelin [2] http://www.infoq.com/presentations/ClojureScript-Javelin
Just watched it and his response is definitely not about the kind of FRP I'm talking about here, but seems to be criticising a specific interpretation of continuous FRP.
When asked what is the right direction he explicitly mentions that it's when all your data is immutable, which definitely applies to Javelin.
When asked what is the right direction he explicitly mentions that it's when all your data is immutable, which definitely applies to Javelin.
It's not classic FRP, but you're basically describing core.async. Have you looked at that at all?
Core async is also an example of a very powerful macro that rewrites execution flow; but they do decidedly different things.
While Core Async is about powerful non-threaded coordination of processes, Javelin is about creating self-updating non-cyclical function graphs.
Basically it's about automatically keeping a derived a view from a small set of data up to date when the source data changes.
It's the exact same thing a spreadsheet does for numbers, but becomes much more interesting when the derived view is a DOM tree derived from database+view state.
FWIW; I was inspired by the the work of Kenny Tilton (a.k.a. Smuglispweeny) and his Cells library and manifesto [1]. His work seems to be falling in disarray, but there's still some stuff up on the wayback machine [2][3]
[1] http://smuglispweeny.blogspot.nl/2008/02/cells-manifesto.htm...
[2] https://web.archive.org/web/20080925125040/http://www.tilton...
[3] https://web.archive.org/web/20080925113544/http://bc.tech.co...
While Core Async is about powerful non-threaded coordination of processes, Javelin is about creating self-updating non-cyclical function graphs.
Basically it's about automatically keeping a derived a view from a small set of data up to date when the source data changes.
It's the exact same thing a spreadsheet does for numbers, but becomes much more interesting when the derived view is a DOM tree derived from database+view state.
FWIW; I was inspired by the the work of Kenny Tilton (a.k.a. Smuglispweeny) and his Cells library and manifesto [1]. His work seems to be falling in disarray, but there's still some stuff up on the wayback machine [2][3]
[1] http://smuglispweeny.blogspot.nl/2008/02/cells-manifesto.htm...
[2] https://web.archive.org/web/20080925125040/http://www.tilton...
[3] https://web.archive.org/web/20080925113544/http://bc.tech.co...
Is it just me, or does the fact that every other language is getting translated to Javascript suggest a lot of problems with the language that so many people are willing to write translators?
(I am not a big fan of JS myself, but I also don't feel I have used the language enough to be competent with it).
(I am not a big fan of JS myself, but I also don't feel I have used the language enough to be competent with it).
I'm more inclined to believed that people want to run their programs in a browser, and js is a requirement in that runtime environment.
Most devs are sadly quite reluctant to trying out new languages, and would rather recompile.
Most devs are sadly quite reluctant to trying out new languages, and would rather recompile.
I wouldn't expect any of my Python code to just run in the browser, whatever translation layer I am using (ok, maybe small snippets, but not any code that does anything significant). Its basically a whole different platform you are coding.
No, but a lot of devs are fine switching platforms, but not languages. I don't know why, I think it's fun, but many people are scared of new languages.
Does having a foreign function interface to C mean that C is better?
It's better to see Javascript as a bytecode than as a language in these cases. It just happens that the bytecode looks like the language.
It's better to see Javascript as a bytecode than as a language in these cases. It just happens that the bytecode looks like the language.
It has absolutely nothing to do with the quality of the language and entirely to do with the reach of the platform. People aren't writing transpilers so they can get Haskell to run on Rhino.
"Try running phpjs (JavaScript → PHP) in PHPPHP (PHP → PHP) in PHP.rb (PHP → Ruby) in HotRuby (Ruby → JavaScript) in Narcissus (JavaScript → JavaScript) in Narcissus (JavaScript → JavaScript)!"
Here's C in Common Lisp: https://github.com/vsedach/Vacietis#readme
Omission: there's a very nice on-the-fly compiler, which supports writing an embedded intepreter, for (an old dialect of) Lua in OCaml, written by Norman Ramsey [1]. It's part of the C-- distribution [2].
[1]: http://www.cs.tufts.edu/~nr/pubs/maniaws-abstract.html
[2]: http://www.cminusminus.org/c-downloads/
[1]: http://www.cs.tufts.edu/~nr/pubs/maniaws-abstract.html
[2]: http://www.cminusminus.org/c-downloads/
It would be interesting to do a "chineese whispers" type experiment on these and see what comes out at the end of translating code through multiple languages.
It seems a bit arbitrary to omit mention of Lua's native ability to be trivially embedded in C and C++ programs. Why limit yourself to transpilers?
Yeah I thought it was odd when they had N/A for Lua to C++. They have Clojure listed at Clojure to Java, why not have Lua listed as Lua to C++? It's darn close to the same thing.
Cibyl and NestedVM seem to be in the wrong cell. These take C/C++ source and produce Java. Come to think of it, the Java target should probably be "Java/JVM" as NestedVM can skip Java, going straight to JVM bytecode.
Another suggestion of code I've played with before: http://IKVM.net to run Java (JVM bytecode) on C#, errr, .NET CIL.
Another suggestion of code I've played with before: http://IKVM.net to run Java (JVM bytecode) on C#, errr, .NET CIL.
Nice. Some observations:
Many languages compile to JavaScript(has highest number of source languages).
Java(I think JVM) and C++(native binaries??) has higher source languages.
Clojure has highest target languages(good to learn then).
Java to Java => Beanshell is interesting.
Java(I think JVM) and C++(native binaries??) has higher source languages.
Clojure has highest target languages(good to learn then).
Java to Java => Beanshell is interesting.
This indicates that JavaScript is a pain in the ass, which it is.
This is neither an argument against JavaScript nor was it indended as one, just a personal observation from a long-time JavaScript programmer.
This is neither an argument against JavaScript nor was it indended as one, just a personal observation from a long-time JavaScript programmer.
> This indicates that JavaScript is a pain in the ass
Or as another commenter pointed out that people want to write for the browser and want to use their favourite language to do so.
Or as another commenter pointed out that people want to write for the browser and want to use their favourite language to do so.
Maybe when analysing the stats it helps to distinguish between the intention of the one implementing the transcompiler (e.g. fun, proof-of-concept, research, money, actual need in a project, ...) and the size of the user-base of the transcompiler (in relation to the user-base of the language that is transcompiled to).
Lets say JS's user-base is pretty huge in relation to other languages (which is not an argument for JS). The stats show that a lot of languages transcompile to javascript, so I would indicate a real need for such projects, otherwise there would probably just exist a few as fun/proof-of-concept-projects.
Similar situation for C/C++ (maybe due to lack of high-level features) and Java (due to lack of practical features).
On the other hand: languages that only have a few or no transcompilers that compile to them, does not mean, they are better useable. There could be other things that make writing transcompilers very hard.
Lets say JS's user-base is pretty huge in relation to other languages (which is not an argument for JS). The stats show that a lot of languages transcompile to javascript, so I would indicate a real need for such projects, otherwise there would probably just exist a few as fun/proof-of-concept-projects.
Similar situation for C/C++ (maybe due to lack of high-level features) and Java (due to lack of practical features).
On the other hand: languages that only have a few or no transcompilers that compile to them, does not mean, they are better useable. There could be other things that make writing transcompilers very hard.
Maybe the fact that there are many compilers that target language A means that either language A is easy to target (so transforming to it is a fun hack) or no-one wants to program directly in language A or both (or more). I believe an example of A is JavaScript.
No entry for (Common Lisp → Common Lisp) or (Scheme → Scheme)?
This is pretty great, thanks! I would love to see the top row with the language names move down with the page. I really think that would make this easier to read.
I am astonished that PyPy does not appear on this chart.
PyPy is an implementation. I guess you could call it manually to output C code (then it would sit next to Shedskin), but it isn't normally used that way.
I think there should be bounties for getting certain paths through the transpiler graph working.
I think there should be bounties for getting certain paths through the transpiler graph working.
Various of the other things in there are implementations. To take a direct parallel, compare it with PHPPHP. PyPy allows you to run Python code inside any Python implementation.
You are correct, it should totally be on this list. Both as Python on Python and Python -> C.
It does, but for some reason in the Python -> Scala category
I'm more surprised that Cython isn't there.
I sent a pull request, maybe it will be soon.
Now it is in the wrong column: Python → Scala.
I have to agree with Yegge, good tools are a big problem (http://googlehow.com/2013/10/09/stanford-seminar-googles-ste...). His project becomes more important as more compilers are written - I hope it exists outside Google someday.
no need to learn javascript as all languages can compile into it. :D
Nice.
Isn't it a bit odd that "C/C++" is a single category? That works in certain contexts, but certainly (1) C is a much more common compilation target than C++, and (2) C is much easier to handle as a source language than C++. So in this table it does not make sense to think of the two as one thing.
Isn't it a bit odd that "C/C++" is a single category? That works in certain contexts, but certainly (1) C is a much more common compilation target than C++, and (2) C is much easier to handle as a source language than C++. So in this table it does not make sense to think of the two as one thing.
Take the languages which can be compiled to Java bytecode, throw in IKVM.NET, add the list of languages which can be compiled for the CLR, and you might have the longest list of languages which can run on one platform?
Then consider that Javascript runs on the JVM, and add every language which can be compiled to Javascript.
Then consider that, via Emscripten, any language which targets LLVM can be compiled to Javascript, so add every language with an LLVM frontend.
The consider that C has an LLVM frontend, and add every language which can be compiled to C.
Yes, indeed! We now live in a time where your Chicken Scheme codebase can be compiled to C, then compiled to Javascript, then intepreted in a Javascript interpreter that is being interpreted on a Java interpreter that is being interpreted on a .Net interpreter.
Then consider that, via Emscripten, any language which targets LLVM can be compiled to Javascript, so add every language with an LLVM frontend.
The consider that C has an LLVM frontend, and add every language which can be compiled to C.
Yes, indeed! We now live in a time where your Chicken Scheme codebase can be compiled to C, then compiled to Javascript, then intepreted in a Javascript interpreter that is being interpreted on a Java interpreter that is being interpreted on a .Net interpreter.
Almost. The JavaScript bytecode is turned into JVM bytecode which is then turned into CLR bytecode which is then JITted and runs as compiled native code. I think. Did I miss something?
C++ on C++ = Cling, although it's a bit physics centric
There was a similar project mentioned here before showing transpiler chains, can't find it. Seems like it should be mentioned.
A quine perhaps? (Perhaps Endoh's crazy quine? https://github.com/mame/quine-relay)
No it wasn't a quine, it was in the same spirit as the linked page, a transpiler graph.
Very nice. It looks to me like PHP.rb should be in Ruby -> PHP rather than PHP -> Ruby.
no mention of recently announced scala.js. Otherwise, good job, I'll be monitoring the list!
Python -> Scala = PyPy?
I'm starting to get my hopes up for a world where a Clojure FRP core drives apps in a host of target languages.