>I've heard pure functions described as "having no side effects". So "being pure" means having no state of its own, as well as not having an effect, changing th

>I've heard pure functions described as "having no side effects". So "being pure" means having no state of its own, as well as not having an effect, changing the state of anything anywhere else. This is correct. The "state" part of the equation is equivalent to IO. You either manipulate state, or you manipulate the state of the real world (aka IO). The key is to segregate state and IO away from purity. >Doesn't that describe Object-Oriented Programming, at least some aspect of it, like classes which bind state and methods together? The difficulty, in my experience, is that there can be many, many objects with their own state, affecting each other's state in a complicated web/graph of effects. Yes. OOP by nature unionizes state and method. That is the very definition of an object. But this is not exclusive to OOP. You can do this with any programming paradigm except for strictly functional programs that force you to segregate mutating state and function. >This approach of "pushing state up" to the surface, I think is the way to keep all states in one place, with every change under control. Better yet, to have immutable state, with every effect/change producing a new state. Yes. But the problem is If we truly had immutable state and we produced new state every time this will in the most practical cases lead to a OOM error. We must at some point change state in order to save memory. >In this context, does a combinator mean something similar to a pure function? I see on Wikipedia: Similar. The free variable restricts modularity of the function. x = 5 f(n) = n + x vs. g(n) = n + 5 g is more modular then f because f cannot be moved out of the context of x. g is the combinator while f having a free variable x is not a combinator. This is why the combinator is the most modular primitive. >Right, I think years of programming have taught me to intuitively notice mutable state, especially when a function is trying to reach out and make an effect on some state outside itself. That goes against modularity, unless it's managed intentionally. Exactly and the way to manage it intentionally is to minimize the need for management as much as possible. Remove all logic away from mutations. Mutation is division by zero. Minimize this action as much as possible. Additionally treat mutation and IO as the same thing. You are either mutating state or mutating the world.