Sounds good when you know nothing but Java and never heard of CL - knew nothing about, say (disassemble #'foo) or what is FFI etc.
This is also very telling - lets you deploy your Clojure Web app to a JBoss server and take advantage of JBoss’s scalability without any XML configuration. You get a mature enterprise-ready Java server without the pain of Java or of configuration.
I wonder how many orders of magnitude difference in "scalability" we would see with a simple nginx -> fastcgi -> sbcl setup.)
Memory usage under long periods of time with pending storage/back-end calls is also interesting topic - how JVM blows up just after few hours in "production".)
That's unnecessarily dismissive. CL is a wonderful language, but it's gathered a lot of cruft over the years and essential features like multithreading are not standardized.
More importantly, it doesn't have a focus on immutability and functional programming by default.
I'm not even sure what you mean about the JVM blowing up after a few hours... Tuned correctly it'll stay up indefinitely.
In what way? The Common Lisp standard hasn't changed since 1994.
> essential features like multithreading are not standardized
No one has made up their minds what the best atomic test-and-set operations are. A lot of platforms can't even agree on semaphores vs. condition variables. Which concurrency primitives do you think should be standardized, and which should be left to libraries? To me that seems like a trick question, because there's no good answer.
For example, I think software transactional memory is a dead-end, and shouldn't be part of a language standard, but many people involved in Clojure obviously disagree.
> More importantly, it doesn't have a focus on immutability and functional programming by default.
You can always do FP in Common Lisp, but you can't do gotos in Clojure.
I really wish this were true because I write a lot of Emacs Lisp (closely related to CL), but it's not.
If you don't have immutable lists and strings built-in to the language, you never know whether a given library function is going to assume it's fine to just bash the data in place. And that's not even getting into fundamental equality issues: http://home.pipeline.com/~hbaker1/ObjectIdentity.html
It depends on what you want to do. With a large Java ecosystem not having easy FFI may not be a big deal.
CL, and SBCL, are great, but SBCL uses a conservative garbage collector (or at least it did the last time I used it) so I'd say the chances of having memory problems with Clojure are less than with SBCL. In fact I remember having some memory issues with SBCL though I no longer remember the details.
Being able to disassemble functions is a great but honestly I don't miss that option in Clojure.
Clojure's a great language that's really worth trying out. I'm not saying it's perfect, there are still warts, but it's immensely satisfying too.
The main issue is that Clojure happens to be more enterprise friendly than traditional Lisps.
It is easier to give a jar to the devops team, than trying to convince them to add support for yet another language the crazy developers are now trying to use.
This is also very telling - lets you deploy your Clojure Web app to a JBoss server and take advantage of JBoss’s scalability without any XML configuration. You get a mature enterprise-ready Java server without the pain of Java or of configuration.
I wonder how many orders of magnitude difference in "scalability" we would see with a simple nginx -> fastcgi -> sbcl setup.)
Memory usage under long periods of time with pending storage/back-end calls is also interesting topic - how JVM blows up just after few hours in "production".)