I've seen a lot of code that was larger than necessary because the author didn't know what a Monoid or Functor were. Cf. "Visitor pattern" I wasn't ignorant e

I've seen a lot of code that was larger than necessary because the author didn't know what a Monoid or Functor were. Cf. "Visitor pattern" I wasn't ignorant enough at the time I wrote the code to fuck up in the way you describe. I can only show an example of stuff I've made. Here we go, three more uses of Monoidic functions (mempty, mappend) https://github.com/bitemyapp/bloodhound/blob/master/Database/Bloodhound/Client.hs#L174-L178 https://github.com/bitemyapp/bloodhound/blob/master/Database... It's not just about code, it's about conceptual memoization. If you know what a Monoid is and you're learning how a data type like ByteString works, you can intuit how to "stitch" bytestrings together as well as how to get an "empty" ByteString. It's about killing off unnecessarily ad-hoc APIs as much as anything. Being able to realize when you're implementing a Functor/Monoid/Applicative/Monad is powerful because it lends you intuition on what the rules for a well-behaved API are and allow powerful, polymorphic code-reuse. Consider the reusability of the functions here across the vast set of Monadic types out there: http://hackage.haskell.org/package/base-4.7.0.0/docs/Control-Monad.html http://hackage.haskell.org/package/base-4.7.0.0/docs/Control... This is worth pondering as well: https://github.com/jwiegley/simple-conduit https://github.com/jwiegley/simple-conduit The code savings described are usually associated with not having to rewrite the polymorphic generic functions used in the Haskell ecosystem for the one-off a person made. The conceptual power from having a community that understands these patterns is more important. You'll learn more and faster by learning Haskell. https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell