This article is the first in a series about how to incorporate functional programming concepts into Ruby code, in a pragmatic way – something I call “functional style.”

And when I say pragmatic, what I mean is that the code should still mostly look and feel like idiomatic Ruby. Ruby is not Haskell, and nor should it be. The idea is to work with the grain of the language, not against it. The code should be easy for any Rubyist to understand – hopefully even easier than what you’re accustomed to.

So let’s kick off the functional style series with avoiding mutation: the benefits, how to do it, the drawbacks, and where it might not be appropriate.