Re: Actors not good for concurrency model
Let me make clear that i agree with you... if you look at java solutions to those issues .. they are complete inellegant and almost force you to deadlocks or bad performance using locks (coming back to single threaded performance)... so actors are far way better then the usual approach... the thing is, looking in the FP paradigm, it almost enforce you to create black boxes.. since you dont need to return anything to the caller.. nobody claiming that monads are perfect.. but i think solutions are possible, like future-promisse for instance.. you could launch the threads and have a monitor or a thermometer to it... its returning you something... if we dont take care, and dont worry about functional purity.. in can use it as your in-house project.. when YOU know what happen, and get everything under control.. but when it cames to publish a library to share some functionality.. it will end us all open the source and putting our stuff inside, making a different beast everytime... i think it was that the oop comunnity fail to address.. i cant remember the time a get a third part java library ...and in fact you have to compose/embed a hole java application like you end up doing it with jetty for example.. we dont have to pursuit purity at all cost.. and fell a sinner when we dont acomplished that.. is just if we achieve that it will make things better to us.. thats a nice goal to try any effort pursuing to solve dificult problems are venerable, actors are one of them... but we must have our critical eyes open to understand the limits of what you can do with every solution... technology are not to be understanded as footbal teams or religions , as we must exceede ourselves everyday On Tue, May 18, 2010 at 10:28 PM, Bill Allen b...@k2bea.org wrote: On Sun, May 16, 2010 at 3:19 PM, Fabio Kaminski fabiokamin...@gmail.comwrote: Sorry about using the list like twitter.. but i thought this is a pretty good article about functional programming side effects, and why actors are not very good design decision.. Actors not good for concurrency model : http://pchiusano.blogspot.com/2010/01/actors-are-not-good-concurrency-model.html just another prove that Rich thoughts are pretty concise , and that all are pretty well materialized in clojure's framework. what convinced me to embrace clojure, is that it choose to make the right thing , instead of the popular one.. as haskell community says wisely : avoid success at all costs :) There's no question in my mind that Rich's thoughts are pretty concise. But then again, there's no question in my mind that Joe Armstrong's thoughts aren't also pretty concise. There is no system that can fundamentally guarantee against programming errors in the single core or multi core case. Erlang has provided a number of constructs that mitigate against poor multi-processor programming mistakes, but remember, that's mitigate, not prevent. The article struck me as a long diatribe on a subject that the author knows just enough about to believe he's an expert when he's really just scratching at the surface. Let me be clear. Actors are a proven model to build good, in fact, excellent concurrent and high reliability systems. That statement doesn't take anything away from the advances that clojure is bringing to the state of the art. For us to believe that clojure is pointing the way to a better solution doesn't require us to say that actors/Erlang sucks. -- 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.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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: Actors not good for concurrency model
Actors in Erlang DO have mutable state, you're just discouraged from using it. ;) No really, erl -man get and set. Sometimes you're forced to use this despite the best of intentions. I don't think anyone is trying to claim that it is impossible to mutate shared in state in an erlang actor. The claim is rather that the intended fundamental model implemented by an actor is not one of shared mutable state. -- / Peter Schuller -- 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: Actors not good for concurrency model
On Mon, May 17, 2010 at 11:20 PM, Peter Schuller peter.schul...@infidyne.com wrote: Actors in Erlang DO have mutable state, you're just discouraged from using it. ;) No really, erl -man get and set. Sometimes you're forced to use this despite the best of intentions. I don't think anyone is trying to claim that it is impossible to mutate shared in state in an erlang actor. I'm not sure many people here have any clue what they're talking about, especially when it comes to Erlang. I thought I'd make it clear. The claim is rather that the intended fundamental model implemented by an actor is not one of shared mutable state. I'm not sure why a getValue/setValue is any different from an ='s sign. Instability and unpredictability still results. Be they actors or threads, neither really solves any sort of problem save perhaps atomic updates. This all seems quite far afield of the original claim of the article, which was primarily that Actors are not composable and thus inferior to more functional programming. Even if we lay aside the implicit assumption that composability is a benefit, we're still left with the absurdity of the statement. Monads, one of the more important and critical constructs for purely functional programming, are not composable. The whole thing is absurd, and associating it with anything clojure-esque only lets that absurdity rub off. -- / Peter Schuller -- 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 -- -- Dave Fayram dfay...@gmail.com -- 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: Actors not good for concurrency model
I'm not sure why a getValue/setValue is any different from an ='s sign. Instability and unpredictability still results. Be they actors or threads, neither really solves any sort of problem save perhaps atomic updates. My (unproven) gut feeling is that people are afraid of machine concurrency, and the removal of machine-level concurrency issues (by use of appropriate high-level abstractions) cause a belief, which is in my estimation mistaken, that you are therefor rid of *all* concurrency issues. In any case, for the record, I did not mean to imply that i agreed, overall, with the originally posted article. -- / Peter Schuller -- 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: Actors not good for concurrency model
On Sun, May 16, 2010 at 3:19 PM, Fabio Kaminski fabiokamin...@gmail.comwrote: Sorry about using the list like twitter.. but i thought this is a pretty good article about functional programming side effects, and why actors are not very good design decision.. Actors not good for concurrency model : http://pchiusano.blogspot.com/2010/01/actors-are-not-good-concurrency-model.html just another prove that Rich thoughts are pretty concise , and that all are pretty well materialized in clojure's framework. what convinced me to embrace clojure, is that it choose to make the right thing , instead of the popular one.. as haskell community says wisely : avoid success at all costs :) There's no question in my mind that Rich's thoughts are pretty concise. But then again, there's no question in my mind that Joe Armstrong's thoughts aren't also pretty concise. There is no system that can fundamentally guarantee against programming errors in the single core or multi core case. Erlang has provided a number of constructs that mitigate against poor multi-processor programming mistakes, but remember, that's mitigate, not prevent. The article struck me as a long diatribe on a subject that the author knows just enough about to believe he's an expert when he's really just scratching at the surface. Let me be clear. Actors are a proven model to build good, in fact, excellent concurrent and high reliability systems. That statement doesn't take anything away from the advances that clojure is bringing to the state of the art. For us to believe that clojure is pointing the way to a better solution doesn't require us to say that actors/Erlang sucks. -- 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: Actors not good for concurrency model
far as i know..actors share a mutable queue.. so there's good possibility for dead-locks for scala theres an akka framework , that you can solve that with its actors .. that let me see.. uses a STM.. and its actors are pretty the same as .. clojures agents i think clojure are making disciples in others languages too :) but the greatest argument is the lack of composabillity and reuse that side-effect functions suffer from... the old divide-n-conquer.. On Sun, May 16, 2010 at 9:17 PM, patrickdlogan patrickdlo...@gmail.comwrote: Nice diatribe against actors by someone who's apparently never... actually... used... actors. Clojure is really nice, but that doesn't mean I'm going to buy into weak arguments against features it doesn't have in its core. On May 16, 12:19 pm, Fabio Kaminski fabiokamin...@gmail.com wrote: Sorry about using the list like twitter.. but i thought this is a pretty good article about functional programming side effects, and why actors are not very good design decision.. Actors not good for concurrency model : http://pchiusano.blogspot.com/2010/01/actors-are-not-good-concurrency... just another prove that Rich thoughts are pretty concise , and that all are pretty well materialized in clojure's framework. what convinced me to embrace clojure, is that it choose to make the right thing , instead of the popular one.. as haskell community says wisely : avoid success at all costs :) -- 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.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group athttp:// groups.google.com/group/clojure?hl=en -- 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.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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: Actors not good for concurrency model
far as i know..actors share a mutable queue.. so there's good possibility for dead-locks Actors as they work in erlang don't have mutable state (not intrinsically anyway, though of course you can implement an actor that does poke on shared data since it's your code). The 'state' in an erlang actor is that of parameter(s) to an infinitely tail-recursive function. Deadlock in a message passing system is still possible if you limit the mailbox size (unless some other means are used to prevent it). My understanding is that mailbox size is not limited in erlang, and that there is no other means to avoid deadlock, meaning that while you will not deadlock in the message passing system you can cause memory exhaustion. Disclaimer: While I've played with erlang I'm not really that into it, please correct me someone if I've misrepresented anything. -- / Peter Schuller -- 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: Actors not good for concurrency model
Actors in Erlang DO have mutable state, you're just discouraged from using it. ;) No really, erl -man get and set. Sometimes you're forced to use this despite the best of intentions. But I really have to ask, how composable were monads again? - dlf On Mon, May 17, 2010 at 3:04 AM, Peter Schuller peter.schul...@infidyne.com wrote: far as i know..actors share a mutable queue.. so there's good possibility for dead-locks Actors as they work in erlang don't have mutable state (not intrinsically anyway, though of course you can implement an actor that does poke on shared data since it's your code). The 'state' in an erlang actor is that of parameter(s) to an infinitely tail-recursive function. Deadlock in a message passing system is still possible if you limit the mailbox size (unless some other means are used to prevent it). My understanding is that mailbox size is not limited in erlang, and that there is no other means to avoid deadlock, meaning that while you will not deadlock in the message passing system you can cause memory exhaustion. Disclaimer: While I've played with erlang I'm not really that into it, please correct me someone if I've misrepresented anything. -- / Peter Schuller -- 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 -- -- Dave Fayram dfay...@gmail.com -- 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: Actors not good for concurrency model
i don't expect it would be hard to write an Erlang program with 2 actors that would deadlock. Of course it wouldn't. as far as i know, people use timeouts on message handling to sweep it under the carpet. Most people probably use the OTP library with well-defined behaviors is what they call them. You write the functions for your application and plug them into the libraries of well-defined messaging behavior. -- 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
Actors not good for concurrency model
Sorry about using the list like twitter.. but i thought this is a pretty good article about functional programming side effects, and why actors are not very good design decision.. Actors not good for concurrency model : http://pchiusano.blogspot.com/2010/01/actors-are-not-good-concurrency-model.html just another prove that Rich thoughts are pretty concise , and that all are pretty well materialized in clojure's framework. what convinced me to embrace clojure, is that it choose to make the right thing , instead of the popular one.. as haskell community says wisely : avoid success at all costs :) -- 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: Actors not good for concurrency model
Nice diatribe against actors by someone who's apparently never... actually... used... actors. Clojure is really nice, but that doesn't mean I'm going to buy into weak arguments against features it doesn't have in its core. On May 16, 12:19 pm, Fabio Kaminski fabiokamin...@gmail.com wrote: Sorry about using the list like twitter.. but i thought this is a pretty good article about functional programming side effects, and why actors are not very good design decision.. Actors not good for concurrency model :http://pchiusano.blogspot.com/2010/01/actors-are-not-good-concurrency... just another prove that Rich thoughts are pretty concise , and that all are pretty well materialized in clojure's framework. what convinced me to embrace clojure, is that it choose to make the right thing , instead of the popular one.. as haskell community says wisely : avoid success at all costs :) -- 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 athttp://groups.google.com/group/clojure?hl=en -- 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
