Observations from a real-world Clojure project
groups.google.com
Observations from a real-world Clojure project
1–10 of 33 posts
Re: Observations from a real-world Clojure project
#2Bah. I still can't forgive Google for wrapping everything sent though Gmail or Groups to 80 characters.
Re: Observations from a real-world Clojure project
#3I'd like to reiterate the lack of good debuggers for not just Clojure, but also free CL implementations. I haven't branched out much recently, but is sbcl/SLIME still state-of-the-art for lisp debugging in the open source world?
Re: Observations from a real-world Clojure project
#4"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?
Re: Observations from a real-world Clojure project
#5"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
#6I'd like to reiterate the lack of good debuggers for not just Clojure, but also free CL implementations. I haven't branched out much recently, but is sbcl/SLIME still state-of-the-art for lisp debugging in the open source world?
I personally use SBCL, but I've heard a lot of people use Clozure Common Lisp (http://www.clozure.com/clozurecl.html) because it has better Slime integration (better stack frame inspector, etc).
The very best tools are probably Allegro CL (w/ its non-emacs IDE) and Lisp Works (and its own IDE too). I've heard nothing but good things about both (and have used Allegro CL enough to know it - and its associated libraries - are very impressive).
As far as I can gather no one really uses them since they are just too expensive though. They must be making money somewhere, I just don't know where ...
Re: Observations from a real-world Clojure project
#7> Example: ~10M records are processed and transformed, various computations occur, and ~100K records are spit out. Lots of statistics. One type of run takes 12 hours on an 8GB, 4-core Linux box
That seems insanely slow, unless they are doing something insanely complex. In other words, this doesn't tell us very much.
Re: Observations from a real-world Clojure project
#8> Example: ~10M records are processed and transformed, various computations occur, and ~100K records are spit out. Lots of statistics. One type of run takes 12 hours on an 8GB, 4-core Linux box That seems insanely slow, unless they are doing something insanely complex. In other words, this doesn't tell us very much.
12 hours / 10,000,000 records = 4.32ms/record concurrently. (4 cores maxed out ≅ 16ms per item?)
Doesn't tell us much, but that doesn't seem insanely slow either, necessarily.
Re: Observations from a real-world Clojure project
#9> Example: ~10M records are processed and transformed, various computations occur, and ~100K records are spit out. Lots of statistics. One type of run takes 12 hours on an 8GB, 4-core Linux box That seems insanely slow, unless they are doing something insanely complex. In other words, this doesn't tell us very much.
My "slow sense" is tingling too. I'm deadly curious to know how fast I could make that "12-hour" job using Scala or Java.
I've done extensive work with Scala, Java, and bytecodes; writing performant Scala code requires some knowledge of the JVM and how Scala is compiled, and requires sacrificing some of its power; but because the static typing and method dispatching is so similar to Java's, you can get there. From everything I've read about Clojure, it sounds a whole level less efficient.
Not trying to knock Clojure, but 12 hours just sounds way way too long without more explanation.
Re: Observations from a real-world Clojure project
#10"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.
OTOH it doesn't really matter whose "fault" it is; if using Clojure causes SEGVs but some other Lisp doesn't cause SEGVs, that's a problem.