3 ms·

> The segregation of state away from pure functions is the "state" of the art right now in terms of modularity. I've heard pure functions described as "having

> The segregation of state away from pure functions is the "state" of the art right now in terms of modularity. 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. > We don't fully know how to maximize modularity when we have state and functions working together.. 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. > functional core, imperative shell 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. > Once your program is in itself a combinator composed from other combinators In this context, does a combinator mean something similar to a pure function? I see on Wikipedia: > Combinatory logic can be viewed as a variant of the lambda calculus, in which lambda expressions (representing functional abstraction) are replaced by a limited set of combinators, primitive functions without free variables. And the meaning of "free variables": > In computer programming, the term free variable refers to variables used in a function that are neither local variables nor parameters of that function. The term non-local variable is often a synonym in this context. Aha, non-local variables. That smells like global or external state. 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.

corethree 3y ago
>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.

corethree 3y ago

>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.