Refactoring Ruby with Monads

Tom Stuart


Monads are in danger of becoming a bit of a joke: for every person who raves about them, there’s another person asking what in the world they are, and a third person writing a confusing tutorial about them. With their technical-sounding name and forbidding reputation, monads can seem like a complex, abstract idea that’s only relevant to mathematicians and Haskell programmers.

Forget all that! In this pragmatic talk we’ll roll up our sleeves and get stuck into refactoring some awkward Ruby code, using the good parts of monads to tackle the problems we encounter along the way. We’ll see how the straightforward design pattern underlying monads can help us to make our code simpler, clearer and more reusable by uncovering its hidden structure, and we’ll all leave with a shared understanding of what monads actually are and why people won’t shut up about them.

Notes for reviewers

The idea here is to pick some familiar problems in Ruby code (e.g. dealing with nil; choosing between shared state and too many method arguments; threading multiple values through a chain of functions; duplicated code with superficial di erences; callback hell) and show how monads can address them.

The general approach is to talk about monads as a design pattern rather than a mathematical concept, by analogy to abstract data types (e.g. a stack): there are just some rules about what operations must be available and what constraints they need to satisfy to qualify as a monad, and once the rules are followed we can get some useful behavior for free.

Edit proposal


Abstractions 2016 - Rejected [Edit]

eurucamp 2014 - Accepted [Edit]

BaRuCo 2014 - Accepted [Edit]

GoGaRuCo 2014 - Accepted [Edit]

Add submission