Newbie: General question about concurrency in Clojure
I'm still getting started with Clojure and I'm wondering about how one should generally go about concurrency and how transparent concurrency is in Clojure. So, to me there would be two approaches: A) Be aware of the parts of your system that will be concurrent and only within these parts write concurrent code using reference types and so on. My question here would be, how much a developer has to scratch his head about concurrency. Agreed, it's much easier than using locks like in Java, but still I have to think about what should be a ref, what should be an agent and how to set up transactions. B) Write concurrent code where you can, even the (smallest) parts of your system which aren't necissarily inherently concurrent. The question here is, if handling concurrency in Clojure is simple enough to go about it this way, or if it would be much less effort to write non-concurrent code. So, in general I think the question is, how transparent concurrency is in Clojure. The ultimate goal would be to just write code, that is concurrent, but to not have to think to much about it. If you like, you could also compare Clojure's approach to actor based models. -- 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
Re: Newbie: General question about concurrency in Clojure
On Mar 9, 9:26 am, Nick Wiedenbrueck wrote: > I'm still getting started with Clojure and I'm wondering about how one > should generally go about concurrency and how transparent concurrency > is in Clojure. So, to me there would be two approaches: > > A) Be aware of the parts of your system that will be concurrent and > only within these parts write concurrent code using reference types > and so on. Basically, yes. But note that any code that doesn't use atoms, refs and other mutable stuff "is concurrent" by itself. The ref types are the ones that require some thought. As a rough rule of thumb, this means you want to keep the number of reference objects down. > My question here would be, how much a developer has to > scratch his head about concurrency. Agreed, it's much easier than > using locks like in Java, but still I have to think about what should > be a ref, what should be an agent and how to set up transactions. You always have this problem. But really, if you're new to clojure, you don't need refs nearly as much as you probably think right now. > B) Write concurrent code where you can, even the (smallest) parts of > your system which aren't necissarily inherently concurrent. The > question here is, if handling concurrency in Clojure is simple enough > to go about it this way, or if it would be much less effort to write > non-concurrent code. > > So, in general I think the question is, how transparent concurrency is > in Clojure. The ultimate goal would be to just write code, that is > concurrent, but to not have to think to much about it. Again, anything that doesn't use mutable objects is automatically concurrent. But I think you're conflating concurrency and parallelism. Joost. -- 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
Re: Newbie: General question about concurrency in Clojure
The answer would be a mix of A and B, mostly because there seems to be an assumption that you have to consider concurrency everywhere in order to be able to have it at some point later. This is not the case. You do tend to be very explicit about concurrency and only use the concurrency primitives (refs, atoms, agents and vars) at a few selected spots, but most of the time you don't have to think about concurrency at all, since even the smallest parts of the system is written in a way that allows for concurrency (by using pure functions and not using the concurrency primitives). Clojure is a functional programming language, which among other things means that computation is in general carried out using referentially transparent (pure) functions. A pure function always return the same value for the same input and is free from side-effects. Pure functions are always thread safe and will never be any problem to concurrency. In a language like Java, mutation of variables and objects is very often used for performing computations. But this intervenes calculations that has nothing to do with each other, since a mutating step in computation A can affect computation B if they operate on the same objects. The result is that in Java, you have to think about concurrency when you perform computations, unlike in Clojure. (Here, I use the word "compute" to mean something like "produce new data of interest".) You tend to write the largest part of a Clojure application as compositions of pure functions. You only have to introduce reference primitives when you have a long-running process whose state changes and evolves over time (for instance a game or a server, or anything that communicates with the outside world and changes thereafter). Clojure acknowledges the need for things to be able to change, but keeps that separate from computation. Most library code I have written hasn't used the concurrency primitives at all. The state changing part of an application often resides at a higher level. // raek -- 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
Re: Newbie: General question about concurrency in Clojure
Thanks for your answers. Guess, I just got a little bit lost after digging deeper into the whole thing. Just didn't see anymore that the core problem is mutability. But it's much clearer again now. -- 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