How are memory protection errors just a footnote?
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 ...
Really? I would have said CCL has worse Slime integration in general (Slime being an epiphenomenon of the SBCL-on-Linux world) and far worse when it comes to debugging. Am I missing something?
We're using CCL with Slime on OS X. The Clozure people are working on a new IDE, but I don't know how good its debugging facilities are yet. It would take a lot to get me off Emacs, but slick debugging might do it.
Alternatively, I often think that maybe we should just take the time to make sldb do what we want. But it's hard to take precious resources away from one's main project.
If anyone feels the same way and is interested in hacking on this, email me - maybe we can work something out.
My understanding is that the two major motivating factors for this decision were that CCL compiles faster and has better debugging support.
This is all based on my memory of conversations that took place about a year ago, so it's entirely possible I'm mis-remembering or what used to be true no longer holds. I have no first hand experience with CCL so if you do, I'll take your word for it ...
Dan Weinreb, another ITA developer, did a talk at Google a few months ago on ITA's new reservation system (the Polaris project you mention). They do use CCL, but the code also compiles and runs with SBCL. The primary reason he cites in that talk for preferring CCL over SBCL (about 22 minutes in) is that CCL compiles code more quickly than SBCL.
I haven't used CCL much, but I understand SBCL and CCL have different debugging strengths. An SBCL developer tells me that a significant chunk of the compilation time for our application is in constraint propagation for types. That's part of the "generates more efficient code", but it also means that it's smart about telling you when you're doing something that's not going to work. For whatever reason, type propagation or otherwise, CCL won't do as much to help you at compile time. I am told that CCL gives better stack traces, so SLIME can help you more.
6. Debugging facilities also have not kept up with the state of
These two are the first thing I check before trying to use any programming language.
That seems insanely slow, unless they are doing something insanely complex. In other words, this doesn't tell us very much.
Doesn't tell us much, but that doesn't seem insanely slow either, necessarily.
Most PC video games, for example, expect a refresh rate somewhere between 30Hz and 60Hz. 60Hz gives you 17ms for an entire frame, in which it's doing an incredible amount of work: drawing a whole scene, updating the world, running physics, etc. etc.
I think you have too low expectations. Modern hardware is very, very fast.
As has been said, though, this is all speculation.
And it's not 4.32ms/rec; that it's 4.32/rec with 4 cores, so estimating around 17ms (like the graphics frame) is closer.
I don't agree with your suggestion that the fact that because graphics is usually accelerated and physics very rarely is, the comparison is unfair. Take a look at Pixomatic that Mike Abrash worked on. DirectX 7-level API, done entirely in software; and efficient enough that the game can still do all its work in its own time. Games still have to pump an awful lot of data through to the hardware; the hardware isn't going to do all the high-level scene graph calculations, culling and occlusion itself. The hardware expects a list of pretty basic primitives, and takes care of transforming them into the view frustum, with depth converting into Z-buffer value. The game still needs to make sure it doesn't give the hardware too much stuff that isn't actually intersecting with the view frustum.
As for the comparison being unfair, the person who initially made that comparison was you, sir. Bringing real-time visual simulation into the equation is unfair for a variety of reasons, including the fact that a lot more research has been done in that field's optimization. I'm not sure exactly what you want from a simple high-level example that "Yes, Clojure can be used to do real work," but I don't think anyone here is going to give it to you if you set such outlandish goals as the tip of a heavily funded branch of computer science and mathematics involving real-time rendering.
If the algorithm is Θ(n*n) it's suddenly a bit more impressive.
But yeah, a comparison with a pure Java or C++ implementation would have been great, both in terms of speed and LOC. However, in the "real world", there usually isn't time for such silly things.
My work isn't really that complex, but it takes ages to compute everything.
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.
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 (transients). I, and no doubt many others, would be genuinely interested in performance studies on more complex concurrency problems I've seen so far.
Its a bit dated ('08), but sounds like the jury is still out on STMs.
Curious as to what you have read regarding clojure performance. I recall hearing Cliff Click giving it a thumbs up at a JVM language summit:
This may also be apropos: