On Dec 14, 2012, at 12:55 AM, Paul Butcher wrote: > On 14 Dec 2012, at 00:30, kovas boguta <kovas.bog...@gmail.com> wrote: > >> My recommendation is either "Persistent Datastructures" or "Database as a >> Value" > > Interesting. I'd be interested to hear others thoughts on this. In particular > Rich's > > Rich - what is the "soundbite description" of Clojure's concurrency model > you're happiest with?
Ah, soundbites, the foundation of modern programmer education :) How about this: "Clojure doesn't need a concurrency model. It has a state model that can be realized in multiple concurrency-safe ways." For the state model: "Separate identities and values" The best thing about Clojure's reference types is that they exist. The best thing about Clojure is that you rarely need them. Certainly, pigeonholing Clojure as STM-based is way off the mark. Also, a chapter on STM that doesn't distinguish Clojure and Haskell's functional STM approach from the ordinary "wrap your old imperative code in transactions" approach is going to miss the biggest point. People reading a chapter on the 'STM model' independent of the functional approach of the languages in which it has succeeded are bound to be disappointed and ill-informed. I'd argue that the 'concurrency model' of Clojure and Haskell is 'functional programming' + reference types. Their STMs are a subset of that. As Kovas has pointed out, the symbiosis of persistent data structures and this reference approach is fundamental. I guess this would be my alternative chapter title proposal: Functional Programming + Reference Types Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
