Re: What concurrency models to document?

Hey, A bit late to the party but something I'd love to see in the book is an approachable summary/description/use cases of the main concurrency models at play today: event-based and thread-based concurrency. I see this section helping people compare Clojure with something like Node.js or Ruby with

Re: What concurrency models to document?

I think that you have to talk about concurrency! It is on everyone's mind. I would like to see the discussion go further than what I have seen in most other Clojure books. If you are REALLY interested in concurrency, you are probably interested in looking at using more than one node in a clu

Re: What concurrency models to document?

Adding my two cents: I'd say immutablity, transactions/refs, futures, and actors. I'd also talk a lot about what I call the "four horsemen of the parallel apocalypse"- race conditions, deadlocks, live locks, and priority inversions. These are all bugs that, while they *can* show up in senquentia

Re: What concurrency models to document?

Brian Marick writes: > Which raises the question: *is* concurrency actually a strong selling > point for functional languages? It definitely was/is for me. I'd avoided threads for most of my career-to-date because in imperative languages any thread could mutate any value to be anything at any p

Re: What concurrency models to document?

> > > You have to put quite a bit of thought in to get things right. > > Which raises the question: *is* concurrency actually a strong selling > point for functional languages? > > Yes, but I would question the concept of "free". I would sell the concurrency features thusly: 1) Assert that functio

Re: What concurrency models to document?

On 8/2/12 10:04 AM, Brian Marick wrote: On Aug 2, 2012, at 8:50 AM, Meikel Brandmeyer (kotarak) wrote: You have to put quite a bit of thought in to get things right. Which raises the question: *is* concurrency actually a strong selling point for functional languages? Sane defaults are a sel

Re: What concurrency models to document?

I don't find it to be one of the reasons I use Clojure... Nor do I find it significantly easier than other options I've used in the past (e.g. Java + Jetlang) I feel like concurrency is the half-truth we tell to encourage borderline adopters or spark interest. I don't believe it's a motivating fac

Re: What concurrency models to document?

On Aug 2, 2012, at 8:50 AM, Meikel Brandmeyer (kotarak) wrote: > You have to put quite a bit of thought in to get things right. Which raises the question: *is* concurrency actually a strong selling point for functional languages? In last year's state of clojure survey [*], concurrency ranked

Re: What concurrency models to document?

Hi, I agree with the previous posters. Concurrency in Clojure is neither free nor automatic. You have to put quite a bit of thought in to get things right. I'm always reminded of the classic memoize discussion. Things like futures or promis

Re: What concurrency models to document?

I find auto-concurrency in clojure to be misleadingly thrown around as free. I think a good description of what is free would be helpful, and examples of concurrency patterns that are still necessary above clojure data structures. A common example from my work is a screen that will need to display

Re: What concurrency models to document?

Hi, I don't like the term auto-concurrency because auto-concurrency doesn't exist. The immutability make easier the concurrency programming because you don't have to manage the shared data but, you always have the synchronising management and write specific code for concurrency (using pmap, futu

What concurrency models to document?

I'm writing a book on /Functional Programming for the Object-Oriented Programmer/. It uses Clojure as the teaching language. Since one of the things that attracts programmers to FP is the hope that ordinary mortals can write multicore programs, I want to have a chapt