Comment by paulkoer | Hacker News Reader

Comment by paulkoer | Hacker News Reader

The one thing I don't understand is why people work on new languages for the browser instead of giving us a platform (virtual machine / intermediate representation, whatever) to implement languages against.

I mean here in this thread we are already seeing it. Some people like semicolons, some people don't. Some people like a prototype based object system, some people like a class based system. And on and on.

I think what would really benefit us is a platform (like a JVM for the browser with a great API replacing the dom) where people could implement languages against. we would get

1) A lot of competition of languages (see what is happening on the JVM right now... Clojure, Scala, Groovy ... you name it), hopefully giving us better languages. Javascript has its strenghts but could you imagine that in such an environment a language that doesn't allow you to test whether or not something is a string would make it very long?

2) People could make their choice and be happy. Then you can program the server and the client in the same language, which is pretty much the main argument for server-side javascript.

Let the languages compete instead of giving us one and now another language for the platform!

I think the Dart VM will be a nice target for compilation from other languages. In general it's easier to put a typed language on an untyped runtime than it is to put an untyped language on a typed runtime.

Before Google I worked on an academic project that built a small Smalltalk-like VM that was also a compilation target for something that was very close to unthreaded Java. Worked pretty well.

> I think the Dart VM will be a nice target for compilation from other languages.

This would indeed be nice but it seems that google wants to push the language more than the VM. I quite get this because saying "you can now run your favorite language for the browser" seems much much more attractive than saying "look we made programming language 1001 and this is what you people should be using now!".

> In general it's easier to put a typed language on an untyped runtime than it is to put an untyped language on a typed runtime.

I have no knowledge of how one would do this but a lot of dynamically typed languages exist for the (I am assuming) statically typed platforms such as the JVM and CLR now.

They do, but it's a heck of a lot of work. The CLR has the DLR (Dynamic Language Runtime) that does a lot of the work for you now, but it's still a pain.

This is what JavaScript is trying to be, with the latest revision. They're explicitly trying to make it a better target language for things like ClojureScript and CoffeeScript.

Well yes, but I think the motivation here is more 'since javascript is the only game in town, we'll have to compile to that'. I am not aware of any changes made to Javascript to make it easier to compile to it. And I don't think anyone would choose Javascript as their runtime environment if they had a choice.

I like Clojure and have dabbled with clojurescript but the workflow feels pretty hacky and it is clear that this is not what javascript was made for.

Do you mind elaborating on the hackish parts of the ClojureScript workflow? It's alpha software at the moment, but we can always use some feedback.

Hello Fogus. What an honor! I loved your book ;)

Well, I am certainly not complaining, I think it is mostly just that it needs to be compiled to javascript and that you need to have the right dependencies in place. If you are compiling from the command line it takes a long time (I know this is caused by the jvm startup time, but it still is a little annoying). I know there are workarounds such as cljs-watch but setting everything up right definitely takes some time. The browser-based Repl is awesome but sometimes breaks, I don't always understand why. I do think there could be some improvements in terms of tutorials but those will surely come (I might write one...)

So if you are using it on a daily basis then all of this probably doesn't matter but it does take a bit to get started. And I think to some part this reflects the fact that, well, Javascript was not really intended to be a platform to be compiled against, it is just used that way because it is the only platform in the browser.

>>> I think to some part this reflects the fact that, well, Javascript was not really intended to be a platform to be compiled against, it is just used that way because it is the only platform in the browser.

I'm not so sure this is the case as it is VERY easy to get started with CoffeeScript and have it watch files for changes (at least on a mac with homebrew).

I've experienced general difficulty getting started with Clojure compared to something like Python or CoffeeScript. I suppose I haven't spent considerable time on it (Clojure is just a hobby for now) but the problems I've run into so far are an out of date version on homebrew (1.2 rather than 1.3) and difficulty just getting a usable REPL going (where I can edit lines and use the up-arrow). I'm very attracted to the aesthetics of Clojure but there is so much friction just to get started that I've only been using 4clojure (try-clojure has been non-functional every time I've tried it). I think this is an area that definitely needs to be addressed for Clojure/ClojureScript to get the mainstream traction that node.js/JS/CS enjoy.

Reply on news.ycombinator.com