Arc Forumnew | comments | leaders | submitlogin
2 points by rocketnia 4906 days ago | link | parent

There's a bigger list of things it doesn't have here: https://github.com/clojure/clojurescript/wiki/Differences-fr...

I'm not worried about its lack of 'eval so much. They're placing a strong emphasis on ClojureScript's ability to leverage the Closure Compiler to weed out dead code. Inasmuch as they encourage dynamic programming techniques at all, they'll end up with dynamically minded libraries that make their compile-time efforts seem weaker than they are. Apparently they draw the line at reflection, and 'eval is beyond that point.

What I'm more worried about is that under the current plan, it looks like there "won't [ever] be" any "thread-related things" (http://cloud.github.com/downloads/clojure/clojurescript/cloj...). I don't find Clojure remarkable for static analysis, for syntax, or for collaboration between programmers. What I find remarkable about Clojure is the way it furnishes its standard libraries with things that anticipate concurrency, so that when people write their own concurrency-related Clojure libraries, they're all likely to synergize with each other.[1] Even if ClojureScript doesn't get to have shared-state concurrency thanks to the JavaScript platform,[2] I think it would be great if its biases could somehow be repurposed for use with web workers or AJAX.

[1] At least I imagine they synergize. I haven't used Clojure or stumbled upon many concurrency-related Clojure libraries, so I hardly know how well they work together in practice.

[2] Go JavaScript platform! XD



2 points by thaddeus 4906 days ago | link

I see the value in (hopefully) having a lisp equivalent of sproutcore technology (http://www.sproutcore.com).

For example, here's a demo, which is a little stale, that shows capturing touches and gestures from mobile devices.

http://touch.sproutcore.com/hedwig/

Having a lisp version of this would rock and correct me if I am wrong, but not having eval or such features would not be a problem.

-----

2 points by Pauan 4906 days ago | link

In practice, in both my Arc and JS code, I use eval only when I absolutely have to... which is almost never. It's usually when I'm doing something incredibly hacky, like trying to eval macros at runtime...

Anyways, the traditional wisdom in JS is to avoid eval as much as possible. 99.99% of the time, eval is bad. It slows down your code, makes things like static analysis harder (or impossible), and it's usually completely unnecessary.

So, I don't see any practical problems with removing eval, but I do see some philosophical problems. eval has been a part of Lisp for so long, that it almost feels like a Lisp without eval isn't really a Lisp...

In any case, from a practical perspective, a lack of eval isn't a big deal at all. But I can see why some people might want eval (for non-practical reasons).

-----