When I first wrote the core.async go macro I based it on the state monad. It seemed like a good idea; keep everything purely functional. However, over time I've realized that this actually introduces a lot of incidental complexity. And let me explain that thought.
What are we concerned about when we use the state monad, we are shunning mutability. Where do the problems surface with mutability? Mostly around backtracking (getting old data or getting back to an old state), and concurrency. In the go macro transformation, I never need old state, and the transformer isn't concurrent. So what's the point? Recently I did an experiment that ripped out the state monad and replaced it with mutable lists and lots of atoms. The end result was code that was about 1/3rd the size of the original code, and much more readable. So more and more, I'm trying to see mutability through those eyes: I should reach for immutable data first, but if that makes the code less readable and harder to reason about, why am I using it? Timothy On Fri, May 16, 2014 at 6:49 PM, Julian <juliangam...@gmail.com> wrote: > A quick shoutout to the Clojure Community - thanks for the way you've all > contributed to make my life (mentally) richer. > > James Reeves (author of Compojure and many other wonderful libraries) made > this interesting comment on Hacker News: > > Clojure has libraries that implement monads, but these aren't often > used for threading state. I can't quite place my finger on why, but in > Clojure I rarely find myself reaching for something like the state monad, > as I would in Haskell. > > >Clojure tends to view mutability as a concurrency problem, and the tools > it provides to deal with mutability, such as atoms, refs, agents, channels > and so forth, are not mechanisms to avoid mutation, as to provide various > guarantees that restrict it in some fashion. > > >It might be that in the cases where I'd use a state monad in Haskell, in > Clojure I might instead use an atom. They're in no way equivalent, but they > have some overlapping use-cases. > > https://news.ycombinator.com/item?id=7751424 > > My question is - have other Clojure/Haskell programmers had this > experience? (ie "I rarely find myself reaching for something like the > state monad"). I'm interested to hear if so, and why. > > JG > > PS If this post is unhelpful, could be worded better - please let me know. > I'm asking out of curiosity, not with intent to troll. > > -- > 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.
