Re: what demonstrates Stuart Sierra's State/Event Pattern
Yes, you can use this pattern to define a mini-interpreter for a stream of events or commands, where each event is represented as a data structure. For example, I've used this pattern to write little scripts, a a collection of maps, for driving an integration test. –S On Monday, May 25, 2015 at 10:57:22 PM UTC+1, piastkrakow wrote: Stuart Sierra, Thank you for the response. I won't take that talk as encyclopedic. The 'chain-consequences' function is very interesting, though it is unfamiliar to me. I am still learning about Clojure. You mention that the State/Event pattern is a common one. If you were talking about architectures, I would say your description reminds me of Kafka (events are data structures, replaying events can replay the whole history of state in the app, etc) but I am curious where you feel this pattern shows up as a design pattern? I assume you mean to broadly define this to include those situations where we might use pure functions in loop or reduce to iterate over a message where the message is some data structure, perhaps a JSON document, or some other kind of seq generated by an event? -- 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: what demonstrates Stuart Sierra's State/Event Pattern
This is a pattern I have used **occasionally**. That whole talk is just patterns that were in my head at the time. Take whatever you find useful from it, but don't treat it as a universal or complete list. If you squint, that 'chain-consequences' function behaves sort of like a monad, but I won't claim it's properly monadic according to anyone's definition. –S -- 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: what demonstrates Stuart Sierra's State/Event Pattern
Stuart Sierra, Thank you for the response. I won't take that talk as encyclopedic. The 'chain-consequences' function is very interesting, though it is unfamiliar to me. I am still learning about Clojure. You mention that the State/Event pattern is a common one. If you were talking about architectures, I would say your description reminds me of Kafka (events are data structures, replaying events can replay the whole history of state in the app, etc) but I am curious where you feel this pattern shows up as a design pattern? I assume you mean to broadly define this to include those situations where we might use pure functions in loop or reduce to iterate over a message where the message is some data structure, perhaps a JSON document, or some other kind of seq generated by an event? On Monday, May 25, 2015 at 9:36:39 AM UTC-4, Stuart Sierra wrote: This is a pattern I have used **occasionally**. That whole talk is just patterns that were in my head at the time. Take whatever you find useful from it, but don't treat it as a universal or complete list. If you squint, that 'chain-consequences' function behaves sort of like a monad, but I won't claim it's properly monadic according to anyone's definition. –S -- 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: what demonstrates Stuart Sierra's State/Event Pattern
Almost any event-sourcing system is built like this. Datomic is (more-or-less) an example of this as it tracks all past transactions and keeps indexes that are aggregates of the entire state of the DB. In addition, Greg Young introduced a event store at CodeMesh 2013 that uses this model: https://vimeo.com/84314441 Timothy On Sat, May 23, 2015 at 10:15 PM, piastkra...@gmail.com wrote: I am watching this video, Stuart Sierra's 2012 talk about Functional Design Patterns: http://www.infoq.com/presentations/Clojure-Design-Patterns His description of event sourcing for functional programming emphasizes: recreate past states recreate any past state by reducing over events just store the inputs cache any intermediate state lost of flexibility every event to the system is a data structure problem: perhaps too many data structures I'm curious where is this pattern actually used? -- 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. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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: what demonstrates Stuart Sierra's State/Event Pattern
Thank you for that. I'm curious, when Stuart Sierra mentions a sequence monad, does he offer this example simply to keep the Haskell programmers happy, or is he suggesting that Clojure programmers sometimes use this pattern? I am especially puzzled by this code that he offers, since this does not resemble anything that I am familiar with: (defn chain-consequences [initial-state consequence-fns] (loop [state initial-state fs consequense-fns output []] (if (seq fs) (let [events ((first fs) state) new-state (reduce update-state state events)] (recur new-state (rest fs) (into output events))) output))) On Sunday, May 24, 2015 at 11:11:03 AM UTC-4, tbc++ wrote: Almost any event-sourcing system is built like this. Datomic is (more-or-less) an example of this as it tracks all past transactions and keeps indexes that are aggregates of the entire state of the DB. In addition, Greg Young introduced a event store at CodeMesh 2013 that uses this model: https://vimeo.com/84314441 Timothy On Sat, May 23, 2015 at 10:15 PM, piast...@gmail.com javascript: wrote: I am watching this video, Stuart Sierra's 2012 talk about Functional Design Patterns: http://www.infoq.com/presentations/Clojure-Design-Patterns His description of event sourcing for functional programming emphasizes: recreate past states recreate any past state by reducing over events just store the inputs cache any intermediate state lost of flexibility every event to the system is a data structure problem: perhaps too many data structures I'm curious where is this pattern actually used? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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.
