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  already enables  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.
When asked what is the right direction he explicitly mentions that it's when all your data is immutable, which definitely applies to 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 . His work seems to be falling in disarray, but there's still some stuff up on the wayback machine 
(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.
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.
Or as another commenter pointed out that people want to write for the browser and want to use their favourite language to do so.
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.
The consider that C has an LLVM frontend, and add every language which can be compiled to C.