<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Haskell is more restrictive than Clojure, not less. The language defined by Haskell 98 has no way whatsoever to perform assignment. Monads provide a way to *simulate* assignment, but what they actually do is not assignment (much less simple assignment).</blockquote>
<div> </div><div>Yes, Haskell is a 'purely' functional language so it may 'appear' more restrictive than Clojure but that is not the case at all. Let's not get hung up on semantics : both references and arrays can live in state monads or the IO monad. These are two methods of structuring imperative effects in Haskell. Haskell has many mutable data structures too (as does Clojure, it's built on Java). Haskell also has variable binding (as does Clojure). Refs and Agents in Clojure are fine if that's your thing. I'd argue that other languages do a much nicer job of this. Also, Haskell being a 'purely' functional language has nothing to do with it's concurrency features. For that 'Concurrent Haskell' has been put forward by SPJ etc. but this is an explicit extension to the language that allows atomically-mutable state in concurrent applications. It's arguable that Haskell has been through years of trying to be 'purely' functional with hardly much success.<br>
 <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Clojure takes the same approach to managing threads that Common Lisp does to managing memory allocation. If Clojure's design in this area represents "patronizing assumptions", then so does Common Lisp's memory-management design.</blockquote>
<div> </div><div>Memory-management is a completely different problem that requires a different solution than does concurrent programming. Memory allocation is always required by any program. Any language designer making that assumption is always correct. The same assumption cannot be made by a language designer about concurrency.<br>
Who's to say that the user will always be writing concurrent programs ? 'Everything looking like a nail' and all that.<br>This problem exists at another level and is best handled by the programmer. Sure it's nice to make such an assumption at a language design level if you must but make it optional and in doing so allow the programmer more power.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Common Lisp is designed to make winning easy in the area of memory management. Clojure takes that design as a given, and in addition is designed to make winning easy in the area of concurrent programming. If you really want malloc and free, don't use Common Lisp. If you really want locks and simple assignment, don't use Clojure.<br>

</blockquote></div><br>Clojure has intentionally ignored many approaches taken in CL (not a judgment, just an observation).<br>Many choices were made because of Clojure's foundation (the JVM) and this shows through when programming in the language beyond any trivial examples. Customer approved platforms, existing investments and the 'industry standard' all factored heavily in Clojure's design at some cost to giving the user more power (it's all on the Clojure website). This makes for Clojure being the 'industry standard' Lisp, for better or worse. Clueless managers may end up praising it the way they did Java after reading about it in some magazine.<br>
<br>That's all fine, but another problem that Clojure faces is the marriage of a language trying to be 'purely' functional on top of a platform(including libraries) that will always be imperative. <br>Java was never just a language, it's always been a language, the jvm and the libraries. <br>

Clojure inherits the legacy of all this because of it's design.<br>The magnitude and scope of these problems is yet to be discovered by the Java/Clojure community when they get into building real systems and extending current systems on the JVM with existing libraries.<br>
My bet is that you'll probably see lots of users effectively programming in Java (but using s-exps) when they realize that using the language with existing Java libs is a complete impedance mismatch. You'll likely hear the more experienced Clojure users suggest wrapping these problems up in macros or something. Who wants that job ?<br>
<br>Good luck ...<br><br><br>