Thursday, July 21, 2011

On the absence of EVAL in ClojureScript

[I got bored with the original text of this post. In short: the authors of ClojureScript have taken the pragmatic approach of reusing Clojure-on-the-JVM to generate JavaScript. This means there can be no EVAL in ClojureScript. I think that's sad because Lisp is one of the finest application extension languages, and without EVAL you can't do a really extensible app. Apparently, the ClojureScript authors view the browser-side as something of an adjunct to server apps. In my view, all the action of the future will be in the browser, and not on the server.]

9 comments:

mtraven said...

Especially since the underlying JavaScript engine does have eval...that seems rather backward, doesn't it?

fogus said...

> that seems rather backward, doesn't it?

But the Javascript eval doesn't evaluate ClojureScript. The workflow is such that the runtime environment doesn't need a compilation nor an evaluation piece.

Paul Michael Bauer said...

@fogus
No eval means you can't rev in a live environment. The instant feedback loop lispers are used to is muted due to reving inside a quasi-repl: Rhino from ClojureScript/Closure inside Clojure repl and no live DOM.

Rich's point that we don't need a dev environment in production is true, but brushes over the common JS use case of manipulating a live DOM at dev time, which we can't do with ClojureScript?

I understand the architectural trade-offs made that dictate it's omission, but ... it's something I'd like to have anyway.

ClojureScript Compiler as-a-service might be one way to get eval functionality back. At least you could turn it on/off for dev/production that way.

Manuel Simoni said...

It seems to me that the pragmatic choice of implementing ClojureScript on the JVM is the real issue. Saying that for production you don't need EVAL is nonsense. You can't have an interesting app (think Emacs or Autodesk Maya) without a good command language. And without EVAL, you have no command language at all! So for current dumb web apps it may suffice, but certainly not for the future.

Luc Préfontaine said...

Cross-compilation/cross-linking have existed for years.
It's for a very good reason, the targets of these tools are often resource constrained or lack powerful dev tools.

Who wants to develop directly in a mobile or browser ? Nobody.
Carrying a compiler in these targets to emit code just in case you need to eval code on the fly is nonsense.

Emacs is definitively not a production application. It's a developer tool and you would not see any usefulness in running it in a browse or a mobile phone.
AutoDesk Maya is also a bad example. Who would design animations in a mobile or a browser ?

You need close access to your fast and sophisticated video hardware and you need far more power to animations than you need to play them back.

With the ClojureScript REPL running on the JVM, you can test your code before it gets in the browser and then get cross-compiled/optimized for the target.
As far as playing with the DOM, it's totally dynamic through gClosure or your preferred library (assuming it passes the compiler dance).

You should play with it before commenting it. I did so.

Manuel Simoni said...

@Luc: you're not taking the browser seriously. I do. It's where basically all end-user innovation in the next decade will happen. People will design animations in the browser.

Paul Michael Bauer said...

re: creating animations in the browser.
Already done
http://www.automatoon.com/

fogus said...

@pmbauer

> No eval means you can't rev in a live environment.

Not true. See brepl at https://github.com/ibdknox/brepl for one possible approach for revving a live environment. It's not a complete solution at the moment, but the seed is strong. I think the right approach is to treat the browser as something akin to a SWANK-like environment where a page serves as the REPL context.

:F

humasect said...

It would be wonderful to have a Node.js based REPL! Often, JVM can be too much, and all of my Clojure projects are actually ClojureScript anyway. Its faster, less problems with npm than maven, cleaner, more slick, and portable even. Inside Emacs with Slime....