11–20 of 97 posts
Don't compare Clojure to C, comparing it to Python or Ruby makes more sense because they're all high-level dynamic languages. Sure Clojure runs on the compiling JVM but that doesn't put it into another category; you can also JIT compile Python in a few ways. If we can make working websites and even games in Python, we can make them in Clojure too. What kills Clojure for small scripts and not-long-running applications…
How so?
What I would like to see is a `defconstant` macro, which introduces a constant that can not be changed anymore without restarting the JVM. (def x 1) ; x = 1 (def x 2) ; x = 2 now (defconstant y 1) ; y = 1 (defconstant y 2) ; Exception Also a way of fixing functions would be good, so that no lookup is required. Calling such a fixed function has no overhead, it would be a direct call.
As for function lookup, I recommend reading this thread: http://news.ycombinator.com/item?id=2928285 Also, vars are by default static (but can be made dynamic with ^:dynamic).
If Clojure could dump the Lisp image like SBCL's save-lisp-and-die function, the startup time would be greatly reduced. I wonder if JVM itself can dump its current state and then restore execution. Another approach to the problem would be similar to FastCGI: keep one Clojure server process running and execute scripts on it.
> If Clojure could dump the Lisp image like SBCL's save-lisp-and-die function, the startup time would be greatly reduced. I wonder if JVM itself can dump its current state and then restore execution. It's still hard to understand why aren't Oracle working on something like that. It's not as if they don't care about desktop at all -- JavaFX is going to be part of Java8 and they are even working on a new packaging tool…
http://java.sun.com/developer/technicalArticles/Programming/...
Don't compare Clojure to C, comparing it to Python or Ruby makes more sense because they're all high-level dynamic languages. Sure Clojure runs on the compiling JVM but that doesn't put it into another category; you can also JIT compile Python in a few ways. If we can make working websites and even games in Python, we can make them in Clojure too. What kills Clojure for small scripts and not-long-running applications…
>JVM is in a slow death spiral. How so?
In most enterprises, regardless what we think about the JVM, it is still quite healthy.
Clojure runs quite fast, in my experience. I have written an web app http://rssminer.net, in Clojure (and some Java). On a small VPS(512M RAM, 1 core CPU), It can handle about 300 request per second, On my desktop, about 2000 req/s. Which is not slow, at least.
The persistent data structures Clojure use is fast too. I did some test a long ago, It's roughly the same speed as Java collections.
How slow is slow? If it takes me 3 months to deliver a given program in Clojure and 6 to deliver its Java equivalent, the Clojure one already has 3 months of lead. Assuming the Java one is twice as fast, it'll take 45 days to catch up. Development time is expensive, computers are cheap and get twice as fast every year or so. While a long startup time is annoying, it can certainly be optimized out if someone focuses e…
> Development time is expensive, computers are cheap and get twice as fast every year or so.
It's a bit funny that you're citing Moore's law when Clojure is specifically designed to overcome its breakdown and get out ahead of that lagging curve. (Paraphrasing an early talk from Rich Hickey: "The hardware guys are punting!!")
You can turn that right around as fuel for your original point, that Clojure and it's approach to concurrency buys you tons of developer productivity, compared to whacking about in the weeds with Java. I totally agree there, those higher level features are valuable and worth something, but they do not cost nothing.
What I would like to see is a `defconstant` macro, which introduces a constant that can not be changed anymore without restarting the JVM. (def x 1) ; x = 1 (def x 2) ; x = 2 now (defconstant y 1) ; y = 1 (defconstant y 2) ; Exception Also a way of fixing functions would be good, so that no lookup is required. Calling such a fixed function has no overhead, it would be a direct call.
Well, there is defonce [ http://clojure.github.com/clojure/branch-master/clojure.core... ] As for function lookup, I recommend reading this thread: http://news.ycombinator.com/item?id=2928285 Also, vars are by default static (but can be made dynamic with ^:dynamic).
But I would like to have real constants. A final class with a static final field (and potentially type information), or something like that. This would give the optimal lookup time, as the JVM would have the direct address.
When I (defonce x 1) I can still (def x 2), without restarting the JVM. I want this to not be possible with a defconstant.
How slow is slow? If it takes me 3 months to deliver a given program in Clojure and 6 to deliver its Java equivalent, the Clojure one already has 3 months of lead. Assuming the Java one is twice as fast, it'll take 45 days to catch up. Development time is expensive, computers are cheap and get twice as fast every year or so. While a long startup time is annoying, it can certainly be optimized out if someone focuses e…
I get what you're saying, and you're sort of right, but it's still interesting to figure out why that startup time is so slow, or what other things slow it down. That talk from Daniel Solano Gómez about Clojure on Android was pretty interesting in that regard. I would want to encourage that kind of investigation, although this blogpost has a terrifically flamebait title. > Development time is expensive, computers are…
Earlier quoted context omitted.
> If Clojure could dump the Lisp image like SBCL's save-lisp-and-die function, the startup time would be greatly reduced. I wonder if JVM itself can dump its current state and then restore execution. It's still hard to understand why aren't Oracle working on something like that. It's not as if they don't care about desktop at all -- JavaFX is going to be part of Java8 and they are even working on a new packaging tool…
There is something like that as internal research project, but never made into the mainstream JVM. http://java.sun.com/developer/technicalArticles/Programming/...
Earlier quoted context omitted.
>JVM is in a slow death spiral. How so?
Maybe the typical JVM bashing. In most enterprises, regardless what we think about the JVM, it is still quite healthy.
It's not all gloom and doom though; Attila Szegedi is at Oracle now, working on Nashorn - something exciting for Java 8.