Live data from Hacker News

ClojureScript

github.com

81–90 of 95 posts

Re: ClojureScript

#81
post #26
post #22

Earlier quoted context omitted.

All of the core syntax is not currently there, but you're right that ClojureScript only interops with js and not Java. For a more detailed differences list see https://github.com/clojure/clojurescript/wiki/Differences-fr...

Bear in mind that the wording is very careful. We took great pains to say things like "not currently implemented." ;-)

"ClojureScript does not currently support regular expression literals using #"" "

This one seems like a big deal, given how often I find myself using regexes in clojure. Is it on its way and is there a workaround currently?

Re: ClojureScript

#82
post #10

Earlier quoted context omitted.

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.

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?

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.

Re: ClojureScript

#83
ClojureScript is a fantastic piece of engineering. I'm the author of ClojureJS, one of the few Clojure libraries that implemented Clojure to JavaScript translation (with predictable scoping semantics). After having looked over the ClojureScript sources, I'm convinced this is a far more sophisticated compiler with a sound namespace strategy.

The namespace and compile time checks alone are worth the price of admission. Plus macros, which was the biggest motivator for building ClojureJS.

Suffice to say, if ClojureScript (in its current form) had existed 7 months ago, I'd never have considered building anything on my own. That's not to say I'm not proud of ClojureJS. It was born out of a real need that I had, and has been enhanced by some very valuable contributions by people who also shared my excitement for writing browser clients in Clojure.

I still need to understand the Google Closure integration impact, but from what Rich said at the ClojureNYC talk, it sounds worthy of study and adoption.

Kudos to Rich, and the Clojure.Core team.

Re: ClojureScript

#84
post #53
post #46

Earlier quoted context omitted.

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

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.

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.

Re: ClojureScript

#85
post #60
post #53

Earlier quoted context omitted.

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.

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

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.

Re: ClojureScript

#87
post #70

Earlier quoted context omitted.

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

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

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

Re: ClojureScript

#88
post #47

Earlier quoted context omitted.

I presume Closure is only being used as a post-processing step to optimize the javascript that's produced.

False. We're not just talking about Closure. We're talking about Google Closure. They support millions of users with their apps and maintain cross-browser compatibility. Google is doing that huge block of work for ClojureScript in addition to whole-program optimization.

Google Closure is what I'm talking about too. However, it's important to know _which_ Google Closure, as there are a number of components. It seems that the component most used in ClojureScript is the JavaScript optimizer, which is most likely just run as a post-processing step.

Of course, ClojureScript could also be using the Closure Library within the code, which would integrate Closure deeper into the system.

Re: ClojureScript

#89

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.

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.

Re: ClojureScript

#90
The biggest reason I've avoided Clojure in the past was because of the JVM. I know the interop is useful, but I really do not like Java, and the whole thing just stinks.

This, on the other hand, I can get behind.

Post reply on HN