Earlier quoted context omitted.
How can anyone even approach this with a straight face? You don't even know what they are computing! If you want to question clojure's performance for technical reasons, do that. But let's not use feelings, and instincts in discussions about concrete scientific topics. There have certainly been several interesting articles on clojure performance, and work done to improve performance for native data structures (transi…
Then this discussion between Cliff Click and Rich Hickey may be of interest: http://blogs.azulsystems.com/cliff/2008/05/clojure-stms-vs.h... Its a bit dated ('08), but sounds like the jury is still out on STMs.
Observations from a real-world Clojure project
31–33 of 33 posts
Re: Observations from a real-world Clojure project
#32"Everything* just worked. We took a snapshot at 1.1.0, and we didn't update it. [* The JVM does SEGV on us occasionally. Internal error, which we have not diagnosed.]" How are memory protection errors just a footnote?
You shouldn't be able to SEGV a JVM no matter what bytecode you feed it (exempting JNI). So it is a JVM bug.
Re: Observations from a real-world Clojure project
#335. The functionality of the docs hasn't kept up with Clojure. 6. Debugging facilities also have not kept up with the state of Clojure. These two are the first thing I check before trying to use any programming language.
That is true only if you use bleeding edge clojure (EG. 1.1.0), clojure 1.0 docs are very mature. And since 1.1.0 is a developper version at the moment, it appears quite illogical IMO to complain about the state of documentation.