[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.]
Subscribe to:
Post Comments (Atom)
11 comments:
Especially since the underlying JavaScript engine does have eval...that seems rather backward, doesn't it?
> 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.
@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.
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.
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.
@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.
re: creating animations in the browser.
Already done
http://www.automatoon.com/
@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
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....
I'm late for this party.
The action already is mostly on the client side except in those cases where you really don't want the client to have access to the information or process being run. Example: casino games.
This talk is not about if eval is needed or not in env. Clojure is lisp and has homoiconicity. Data are code and code are data. Not allowing to execute what you have just build in language (or during slurping input from other system) is breaking the homoiconicity. Just tell Rich Hickey how he has castrated it's baby and I bet he will fix that.
Post a Comment