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.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-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<clojure%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
