Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Language-Language Matrix

langlangmatrix.com

Post reply on HN
Print view View original

31–40 of 54 posts

Re: The Language-Language Matrix

#31

Post by nilliams »

juliangamble wrote: post #23
mtrimpe wrote: post #21

It's impressive to see how many runtimes Clojure has already been ported to. I'm starting to get my hopes up for a world where a Clojure FRP core drives apps in a host of target languages.

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 an…

> 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.

Re: The Language-Language Matrix

#32

Post by tkirchner »

madhuprasanna wrote: post #8

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.

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.

Re: The Language-Language Matrix

#33

Post by sesm »

mtrimpe wrote: post #21

It's impressive to see how many runtimes Clojure has already been ported to. I'm starting to get my hopes up for a world where a Clojure FRP core drives apps in a host of target languages.

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.

Re: The Language-Language Matrix

#34

Post by nilliams »

tkirchner wrote: post #24
madhuprasanna wrote: post #8

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.

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 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.

Re: The Language-Language Matrix

#35

Post by tkirchner »

nilliams wrote: post #34
tkirchner wrote: post #24

Earlier quoted context omitted.

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 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.

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.

Re: The Language-Language Matrix

#36

Post by mtrimpe »

sesm wrote: post #33
mtrimpe wrote: post #21

It's impressive to see how many runtimes Clojure has already been ported to. I'm starting to get my hopes up for a world where a Clojure FRP core drives apps in a host of target languages.

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 thi…

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

Re: The Language-Language Matrix

#39

Post by danenania »

nilliams wrote: post #31
juliangamble wrote: post #23

Earlier quoted context omitted.

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 an…

> 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…

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.

Re: The Language-Language Matrix

#40

Post by lukev »

mtrimpe wrote: post #36
sesm wrote: post #33

Earlier quoted context omitted.

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 thi…

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 wi…

It's not classic FRP, but you're basically describing core.async. Have you looked at that at all?
Post reply on HN