The Language-Language Matrix
langlangmatrix.com
langlangmatrix.com
I'm starting to get my hopes up for a world where a Clojure FRP core drives apps in a host of target languages.
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.
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.
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.
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.
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
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...
When asked what is the right direction he explicitly mentions that it's when all your data is immutable, which definitely applies to Javelin.
(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).
Most devs are sadly quite reluctant to trying out new languages, and would rather recompile.
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.
Another suggestion of code I've played with before: http://IKVM.net to run Java (JVM bytecode) on C#, errr, .NET CIL.
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 is neither an argument against JavaScript nor was it indended as one, just a personal observation from a long-time JavaScript programmer.
Or as another commenter pointed out that people want to write for the browser and want to use their favourite language to do so.
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.
I think there should be bounties for getting certain paths through the transpiler graph working.
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.
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.