How dangerous is Clojure's immutability assumption?
cemerick: After using clojure as my primary environment for ~ 18 months, and leaning heavily on existing Java libraries for a lot of foundational stuff, I'd say that this is a non-issue.  Of course, you can get yourself into a lot of trouble in any environment, but (at least for me and other experienced Clojure programmers I've worked with and whose results I've looked at) it's rarely nonobvious where unrestrained (i.e. Java-related) mutability is in the mix -- and in those areas, you take all the usual precautions that you would if you were using those mutable libraries in Java.The upshot of this is that if you're using a Java library, you'll generally want to either:(a) build a clojure wrapper API so as to enforce some sane semantics on it (see clojure.contrib.http.agent for a good example of this, where HTTP interactions are wrapped in clojure agents and a good set of convenience functions that make working with the JDK's HttpURLConnection and friends way more pleasant than usual).(b) confine the usage of key Java libraries in such a way that there's a clear line of demarcation between clojure's mutability and concurrency semantics and the free-for-all in the rest of Java.  This is where the big win is in programming Swing interfaces, for example, where your core data model would ideally be implemented using persistent data structures and clojure's reference objects to ensure sane concurrency semantics, and you take all the usual precautions when touching the Swing APIs.