21–30 of 97 posts
It's important to get these distinctions right! Some people, unfortunately, form impressions from headlines and in this case it's extremely inaccurate. If you read the article you'll get the truth - there are startup time problems causing issues with using Clojure for command-line programs.
That's much less damning overall than "Clojure is slow."
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…
For me the more obvious comparison would be with other Lisps. Which, back in the dim past when I was using 'em, were often damn fast.
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'm not sure if they went through with it though
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.
Re: FastCGI approach. You can use Nailgun for all JVM languages: http://www.martiansoftware.com/nailgun/ Note that this addresses JVM startup overhead, but still not Clojure startup overhead (two are separate).
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.
(def ^:const PI 3.14)
Clojure has a slow startup time . It is not in itself slow. It's important to get these distinctions right! Some people, unfortunately, form impressions from headlines and in this case it's extremely inaccurate. If you read the article you'll get the truth - there are startup time problems causing issues with using Clojure for command-line programs. That's much less damning overall than "Clojure is slow."
> How fast is Clojure at running your code once it finally has got going? ... Clojure is on average 4x slower than Java and 2x slower than Scala.
That's pretty freaking slow.
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.
Vars already default static, so we just need to take better advantage of that in the compiler.
All code constantly assumes that the objects behind Vars will change. Let’s say we have `(defn foo [] 1)`. The caller of (foo) will first lookup the address in RAM of the compiled function, and then jump to it. Because of this dynamicy we can redefine foo at runtime: `(defn foo [] 2)`. All callers still function, and will now get the result `2`. In statically compiled languages this would not happen, because `foo` is translated to the direct address of the first function. The concept of replacing functions at runtime doesn’t exist in that way.
But I would like to see an optional “static” programming feature: I want to be able to mark functions as final. This would be nice after major development has happened. A function object that Clojure created could then not be changed any longer, without restarting the JVM. But such functions can be called directly, without any overhead.
Clojure has a slow startup time . It is not in itself slow. It's important to get these distinctions right! Some people, unfortunately, form impressions from headlines and in this case it's extremely inaccurate. If you read the article you'll get the truth - there are startup time problems causing issues with using Clojure for command-line programs. That's much less damning overall than "Clojure is slow."
You should have read the entire article: > How fast is Clojure at running your code once it finally has got going? ... Clojure is on average 4x slower than Java and 2x slower than Scala. That's pretty freaking slow.
It's all relative.
[1] http://shootout.alioth.debian.org/u64q/which-programming-lan...
So does the ClojureScript compiler basically just embed a Clojure interpreter in every file? I'd be interested to see the code prior to optimization.