Re: Rationale behind the naming and semantics for agents.
BTW I did not mean to imply you are wrong, just wanted to give some extra background. He specifically mentions: the problems of distributed programs are much harder - [...] *direct observation is not possible* [...] On Friday, 6 February 2015 13:21:52 UTC, Andre Richards wrote: > > Have a look here: http://clojure.org/state > > In the section *Message Passing and Actors*, he gives his reasoning. > > Basically, Actors were designed for distributed programs, but that comes > with added complexity and a performance hit. He wanted a simpler model, > because he was mainly concerned about concurrency in same-process > programming. > > On Wednesday, 4 February 2015 12:00:51 UTC, Gary Verhaegen wrote: >> >> They are different from actors because Rich is "unenthusiastic about >> actors". I'm not sure there is any single piece of reference where he >> himself describes exactly why he does not like actors, but here is a guess. >> >> Actors have one very desirable property: they encapsulate some state, and >> the actor itself is responsible for managing the synchronisation of that >> state. This is the part about actors that seemed worth having in Clojure. >> >> Actors also have some very undesirable properties, at least according to >> Rich Hickey's aesthetic tastes (or more precisely, what I think his >> aesthetic tastes are based on what I have seen in his speeches and >> writings): they encapsulate behavior in a closed way and they hide their >> internal state. >> >> So, like he often does, Rich separated the essence of actors into >> separate pieces and recombined them in a new way, giving birth to what is >> now called agents in Clojure: a piece of state responsible for its own >> synchronisation, but completely open to behavioral extension and which does >> not hide its internal state. Overall, openness to extension and observable >> state are pretty important values in the Clojure philosophy. >> >> As for the name, I would assume he deliberately chose a word that was not >> widely used yet for any programming language level concept (since this is a >> new concept) but still reflected the notion of individuality and >> responsibility for oneself embodied in the agent's responsibility for its >> own synchronization. >> >> Of course, as agents were part of the initial Clojure release, only Rich >> Hickey can give a definitive answer. >> >> On Wednesday, 4 February 2015, Justin Smith wrote: >> >>> In fact agents in Scala were the only version I found that were like >>> Clojure in design. >>> >>> Beyond the fact that they exist in Scala, and the design goal was to >>> replicate Clojure's agents, I didn't find that especially informative. >>> >>> >>> On Tuesday, February 3, 2015 at 6:59:09 PM UTC-8, Leonardo Borges wrote: > (as opposed to the combined state+behavior version of agents that one > sees elsewhere) > > Did you mean to say actors? Actor is the abstraction that bundles state and behaviour together. Agents are different and in fact, Akka, a popular JVM actor library, provides agents in addition to actors themselves: http://doc.akka.io/docs/akka/snapshot/scala/agents.html Cheers, Leonardo Borges >>> -- >>> 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 >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Rationale behind the naming and semantics for agents.
Have a look here: http://clojure.org/state In the section *Message Passing and Actors*, he gives his reasoning. Basically, Actors were designed for distributed programs, but that comes with added complexity and a performance hit. He wanted a simpler model, because he was mainly concerned about concurrency in same-process programming. On Wednesday, 4 February 2015 12:00:51 UTC, Gary Verhaegen wrote: > > They are different from actors because Rich is "unenthusiastic about > actors". I'm not sure there is any single piece of reference where he > himself describes exactly why he does not like actors, but here is a guess. > > Actors have one very desirable property: they encapsulate some state, and > the actor itself is responsible for managing the synchronisation of that > state. This is the part about actors that seemed worth having in Clojure. > > Actors also have some very undesirable properties, at least according to > Rich Hickey's aesthetic tastes (or more precisely, what I think his > aesthetic tastes are based on what I have seen in his speeches and > writings): they encapsulate behavior in a closed way and they hide their > internal state. > > So, like he often does, Rich separated the essence of actors into separate > pieces and recombined them in a new way, giving birth to what is now called > agents in Clojure: a piece of state responsible for its own > synchronisation, but completely open to behavioral extension and which does > not hide its internal state. Overall, openness to extension and observable > state are pretty important values in the Clojure philosophy. > > As for the name, I would assume he deliberately chose a word that was not > widely used yet for any programming language level concept (since this is a > new concept) but still reflected the notion of individuality and > responsibility for oneself embodied in the agent's responsibility for its > own synchronization. > > Of course, as agents were part of the initial Clojure release, only Rich > Hickey can give a definitive answer. > > On Wednesday, 4 February 2015, Justin Smith > wrote: > >> In fact agents in Scala were the only version I found that were like >> Clojure in design. >> >> Beyond the fact that they exist in Scala, and the design goal was to >> replicate Clojure's agents, I didn't find that especially informative. >> >> >> On Tuesday, February 3, 2015 at 6:59:09 PM UTC-8, Leonardo Borges wrote: >>> >>> (as opposed to the combined state+behavior version of agents that one sees elsewhere) >>> Did you mean to say actors? Actor is the abstraction that bundles state >>> and behaviour together. >>> >>> Agents are different and in fact, Akka, a popular JVM actor library, >>> provides agents in addition to actors themselves: >>> http://doc.akka.io/docs/akka/snapshot/scala/agents.html >>> >>> Cheers, >>> Leonardo Borges >>> >> -- >> 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 >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Rationale behind the naming and semantics for agents.
Thanks, "not widely used" - so I guess it is totally unrelated to "multi agent systems"? http://en.wikipedia.org/wiki/Multi-agent_system On Wednesday, February 4, 2015 at 4:00:51 AM UTC-8, Gary Verhaegen wrote: > > They are different from actors because Rich is "unenthusiastic about > actors". I'm not sure there is any single piece of reference where he > himself describes exactly why he does not like actors, but here is a guess. > > Actors have one very desirable property: they encapsulate some state, and > the actor itself is responsible for managing the synchronisation of that > state. This is the part about actors that seemed worth having in Clojure. > > Actors also have some very undesirable properties, at least according to > Rich Hickey's aesthetic tastes (or more precisely, what I think his > aesthetic tastes are based on what I have seen in his speeches and > writings): they encapsulate behavior in a closed way and they hide their > internal state. > > So, like he often does, Rich separated the essence of actors into separate > pieces and recombined them in a new way, giving birth to what is now called > agents in Clojure: a piece of state responsible for its own > synchronisation, but completely open to behavioral extension and which does > not hide its internal state. Overall, openness to extension and observable > state are pretty important values in the Clojure philosophy. > > As for the name, I would assume he deliberately chose a word that was not > widely used yet for any programming language level concept (since this is a > new concept) but still reflected the notion of individuality and > responsibility for oneself embodied in the agent's responsibility for its > own synchronization. > > Of course, as agents were part of the initial Clojure release, only Rich > Hickey can give a definitive answer. > > On Wednesday, 4 February 2015, Justin Smith > wrote: > >> In fact agents in Scala were the only version I found that were like >> Clojure in design. >> >> Beyond the fact that they exist in Scala, and the design goal was to >> replicate Clojure's agents, I didn't find that especially informative. >> >> >> On Tuesday, February 3, 2015 at 6:59:09 PM UTC-8, Leonardo Borges wrote: >>> >>> (as opposed to the combined state+behavior version of agents that one sees elsewhere) >>> Did you mean to say actors? Actor is the abstraction that bundles state >>> and behaviour together. >>> >>> Agents are different and in fact, Akka, a popular JVM actor library, >>> provides agents in addition to actors themselves: >>> http://doc.akka.io/docs/akka/snapshot/scala/agents.html >>> >>> Cheers, >>> Leonardo Borges >>> >> -- >> 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 >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Rationale behind the naming and semantics for agents.
They are different from actors because Rich is "unenthusiastic about actors". I'm not sure there is any single piece of reference where he himself describes exactly why he does not like actors, but here is a guess. Actors have one very desirable property: they encapsulate some state, and the actor itself is responsible for managing the synchronisation of that state. This is the part about actors that seemed worth having in Clojure. Actors also have some very undesirable properties, at least according to Rich Hickey's aesthetic tastes (or more precisely, what I think his aesthetic tastes are based on what I have seen in his speeches and writings): they encapsulate behavior in a closed way and they hide their internal state. So, like he often does, Rich separated the essence of actors into separate pieces and recombined them in a new way, giving birth to what is now called agents in Clojure: a piece of state responsible for its own synchronisation, but completely open to behavioral extension and which does not hide its internal state. Overall, openness to extension and observable state are pretty important values in the Clojure philosophy. As for the name, I would assume he deliberately chose a word that was not widely used yet for any programming language level concept (since this is a new concept) but still reflected the notion of individuality and responsibility for oneself embodied in the agent's responsibility for its own synchronization. Of course, as agents were part of the initial Clojure release, only Rich Hickey can give a definitive answer. On Wednesday, 4 February 2015, Justin Smith wrote: > In fact agents in Scala were the only version I found that were like > Clojure in design. > > Beyond the fact that they exist in Scala, and the design goal was to > replicate Clojure's agents, I didn't find that especially informative. > > > On Tuesday, February 3, 2015 at 6:59:09 PM UTC-8, Leonardo Borges wrote: >> >> >>> (as opposed to the combined state+behavior version of agents that one >>> sees elsewhere) >>> >>> >> Did you mean to say actors? Actor is the abstraction that bundles state >> and behaviour together. >> >> Agents are different and in fact, Akka, a popular JVM actor library, >> provides agents in addition to actors themselves: >> http://doc.akka.io/docs/akka/snapshot/scala/agents.html >> >> Cheers, >> Leonardo Borges >> > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Rationale behind the naming and semantics for agents.
In fact agents in Scala were the only version I found that were like Clojure in design. Beyond the fact that they exist in Scala, and the design goal was to replicate Clojure's agents, I didn't find that especially informative. On Tuesday, February 3, 2015 at 6:59:09 PM UTC-8, Leonardo Borges wrote: > > >> (as opposed to the combined state+behavior version of agents that one >> sees elsewhere) >> >> > Did you mean to say actors? Actor is the abstraction that bundles state > and behaviour together. > > Agents are different and in fact, Akka, a popular JVM actor library, > provides agents in addition to actors themselves: > http://doc.akka.io/docs/akka/snapshot/scala/agents.html > > Cheers, > Leonardo Borges > -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Rationale behind the naming and semantics for agents.
> > > (as opposed to the combined state+behavior version of agents that one sees > elsewhere) > > Did you mean to say actors? Actor is the abstraction that bundles state and behaviour together. Agents are different and in fact, Akka, a popular JVM actor library, provides agents in addition to actors themselves: http://doc.akka.io/docs/akka/snapshot/scala/agents.html Cheers, Leonardo Borges -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
