Hacker News Reader

Comment by runevault | Hacker News Reader

Node.js + clojurescript just came up in the Demo. Part of me says awesome, another part says "How many hipster programmer brains blew up" <_<.

Overall I'm excited about this and anxious to see how far it can be taken, because if you can write an ENTIRE webapp in clojure is thought provoking.

View on HN

Node.js is the pragmatic choice for ClojureScript command line apps. One of Clojure's weaknesses was that the JVM was not a great choice for these types of scripts. ClojureScript + Node.js effectively solves this problem.

Oh I fully agree with that, and even if we got NOTHING else from this that would be cool. I just can't help from finding some humor in the idea as well.

I don't understand; why bring a web framework into it for command-line work? Is it just that straight-up V8 has a crappy CLI experience?

Web framework? Do you mean Google Closure? If so, bear in mind that the compilation phase will remove unused code, so you're not forced to carry any of it with you if you never use it in your code. As for Node, you do not need it I suppose, but I do not have experience using straight-up V8.

Right, I was talking about node. It sounds like perhaps node has had more people polishing the command-line tools? Stuff that probably belongs in V8, but goes in node because it's a more openly-developed project? The mention of node just seemed a little out of place at first glance.

I only mentioned Node because the parent post did, but as for the reason it was chosen for the target of the first round is because it's definitely got the polish as far as libs, installation experience, etc. go.

Node isn't a web framework, it's more of unixy, network oriented stdlib for v8.

I'm no expert here but I think Node gives you the ability to convey command-line args to JavaScript out of the box. From the brief research I have done, it appears that you need to write a C wrapper to do this with V8. If the JavaScript does not require command-line args, it will run just fine with V8.

I'm glad for the Clojure community if this didn't exist before, but I'm pretty sure Lispers (ie Common Lispers) have written "entire" web apps in Lisp for quite a while[1].

For example, Kenny Tilton wrote a Lisp wrapper to qooxdoo on top of his data-flow library (Cells). The only time we need to write JS code now is for additional glue for widgets or functionality we haven't wrapped yet. And since it wraps qooxdoo, this means not writing (or needing to know) a lick of HTML/CSS. We just write Lisp. And we persist data to a triple store that "shapes" the Lisp/qooxdoo code at runtime.

</smug>

[1] I want to say "years" but I'm not sure how many people have used CL to write "entire" web apps.

I notice you keep replying about Parenscript, but the difference here is important. The reason this is a bigger deal than you make it out to be is because Clojure is hosted on the JVM. That means it's generally had a chance to enter the enterprise, and beyond that, has access to the entire JVM library and interop.

What this means now is, for the first time, you can write Clojure code on the server, interop with legacy Java code or well-tested libraries, and then write Clojure code on the client, full stack. This, as far as I know, is a pretty big game changer since it allows you to write a full-stack web application that is part of the Java ecosystem in a single language that happens to not suck either.

Edit: To clarify, I'm sure there are other JVM lisps, and other Javascript lisps. But this is the first one that is both, I'd wager. This is important.

So the only reason it's a big deal is because it's Clojure? It was only a matter of time this library was written by somebody.

Edit: I guess this somebody also happens to be Rich Hickey. Indeed it would be a big deal if John McCarthy had written Parenscript. :D

To play devil's advocate, wouldn't the exact same thing be possible with the above alternatives and Armed Bear Common Lisp? You can write full-stack in Common Lisp, it's just that different parts need to go through different compilers/interpreters/transformers/what-have-you. Just as it is with Clojure.

No, I think the thing to note here is that Clojure--for reasons I can only guess at--has a lot more sex appeal than CL.

I think if Parenscript were just announced today it would get a big reaction as well. Just like there's a big reaction any time a language comes out and says it can compile down to Javascript. There was a big reaction when a guy did it for C# / XNA, for example.

Just because people are excited about developments in the Clojure ecosystem doesn't mean they aren't excited you can do this elsewhere. It's interesting right now because it's new, and it opens up some new ways of development for people who enjoy writing software in Clojure.

"Just because people are excited about developments in the Clojure ecosystem..."

Good point. My comment was more of a response to the "thought provoking" part rather than being excited about ClojureScript itself.

I could be wrong, but I think this is different. Are there any other languages that are both hosted on the JVM and also in Javascript VMs? Beyond that, there almost certainly isn't a lisp that is.

Java via GWT runs on the JVM and in JavaScript.

Theoretically almost any language that can run on x86 will now run in Javascript thanks to Fabrice Bellard: http://bellard.org/jslinux/

I don't think anyone has managed to get a JVM to run on his Linux port yet though.

More practically, Javascript itself runs fine on the JVM (via Rhino).

There are Ruby-on-JS[1] and Python-on-JS[2] efforts as well (both Ruby & Python run on the JVM)

[1] http://ejohn.org/blog/ruby-vm-in-javascript/

[2] http://pyjs.org/

x86 emulation is the wrong solution to this problem because of the difficulty of interop. Compiling to bytecode at least lets you treat JS functions as FFI calls. The first project to do this was Clue in 2008 (http://cluecc.sourceforge.net/), now all the hype is about emscripten (https://github.com/kripken/emscripten) LLVM bytecode to JS compiler.

Doing compilation GWT/Clojurescript style is going to reduce integration overhead. So far I haven't seen anything that integrates as well as Parenscript.

Yeah, I wasn't too serious about the x86 "solution". It's an impressive hack, but that's all ATM.

I forgot about the LLVM compiler - that's a very promising project.

This is probably missing the point, but JavaScript is hosted on both the JVM and JavaScript VMs (thanks to Rhino). By extension, everything that compiles to JS is hosted on both.

Scheme has Scheme2JS (http://www-sop.inria.fr/indes/scheme2js/) and HOP (http://hop.inria.fr/), which uses Scheme2JS for some interesting RMI stuff.

Parenscript doesn't have a runtime beyond what the JS implementation provides, so it's not really a Common Lisp running on JS, more like a way to compile Common Lisp-based DSLs to JavaScript. Red Daly's PSOS (https://github.com/gonzojive/paren-psos) library provides most of the runtime stuff, and I guess counts as a sort of implementation of CL. I've been toying with the idea of extending PSOS to a full CL in JavaScript.

    possible with the above alternatives and 
    Armed Bear Common Lisp?

Yes it is. I wish being possible was all that it took for it to be done. In the absence of ClojureScript I would love to write my web client code in Common Lisp. I love Common Lisp.

Clojure has had things like Parenscript for a while, including scriptjure (~1.75 years old) and clojurejs.

What's new/exciting/different about ClojureScript? No one has really made it clear here.

Edit: Trimmed unnecessary banter as it's a genuine question.

What would you expect to be different? Your post says the important point: it's Clojure. For some an additonal point is that it's not JavaScript. There is nothing deeper than that.

If that's the most important point I fail to understand why it's #1 Hacker News, sorry. This makes HN no better than a "hype engine" as some say. If someone would at least mention that Google Closure makes it pretty neat, then I would have let it go, so to say.

Even worse, two other relevant Clojure libs are mentioned and the important point is still "it's Clojure"?

The other libraries are clojure libs that implement javascript analogies[1] as clojure macros and functions and generate javascript.

ClojureScript is a Clojure The Language compiler that implements Clojure (its datastructures, standard lib, protocols, deftypes etc etc) and is hosted[2] on javascript rather than the JVM.

In ClojureScript you are not writing reskinned javascript, you are writing Clojure.

[1] simplified for the argument

[2] By outputting javascript

Aha! Great, this is definitely pretty awesome. I don't think anyone's written something like that in Common Lisp yet.

ParenScript (or CoffeeScript) is not the same as ClojureScript. ParenScript "transforms" a subset of CL to JS, while ClojureScript is a full-fledged target runtime for Clojure. For example, something like

  (parenscript:ps (defun square (x) (* x n))) ;; [sic]

will compile fine to "incorrect" JS code. Try doing the same in ClojureScript, you'll get an error/warning from the compiler. This applies to CoffeeScript, etc. as well.

Update - To summarise, ClojureScript is to Clojure what ABCL is to Common Lisp.

Thanks, it makes sense now also thanks to brehaut's comment. I hadn't realized it actually _is_ a Clojure implementation in JavaScript.

Edit: Actually that's not strictly true. "What ClojureScript is Not" https://github.com/clojure/clojurescript/wiki/Core-blog-post...

> (parenscript:ps (defun square (x) (* x n))) ;; [sic]

Why is this example incorrect? n might be a dynamic or global variable; there's no way to know during compilation.

I made something that may give you the same reaction: https://github.com/cretz/gwt-node. It was fun to do, but not sure how practical it is.

Reply on news.ycombinator.com