4 ms·

OOP does not offer true state encapsulation, it just hides it. Objects are always potentially stateful when reasoned about externally. This means that all objec

OOP does not offer true state encapsulation, it just hides it. Objects are always potentially stateful when reasoned about externally. This means that all objects in your system could potentially contribute to the global state space, resulting in a combinatorial explosion of state. This makes programs difficult to reason about and is not a good general approach. In contrast, functional programming makes state explicit. This makes it easier to manage and control state.

TimMurnaghan 9y ago
It's cute how people thing that functional will fix everything. In what way does functional make state explicit? If I look at a structure (if you have one in your language) and ask who changes this part of it across a large code base - it's much worse when you've just got a bunch of functions (with bad names) which can be hiding anywhere. And the "reasoned about" shibboleth. What "reasoning" do you actually do. Don't get me wrong - I have a long history in Lisp and ML and they're good languages in which good people can write good software. But no magic bullets. In another part of the development world I've seen React programmers jumping on the functional bandwagon and deciding that all components have to be stateless. Taking the state outside the components means that we have lots of bugs with mistaken state sharing. So external state doesn't equal well-managed.
- quickthrower2 9y ago
  In functional programming n Haskell functions are pure so there is no state just an input and an output. The exception is the IO entry point. There is a lot of opportunity to sandbox things so that if you know the type of the function you know what it can or can't do to the programs state.
mpweiher 9y ago
> not offer true state encapsulation, it just hides it. That's kind of the definition of encapsulation. > difficult to reason about This is repeated as a mantra without any backup. Most people find state trivial to "reason" about. What becomes more difficult are certain types of proofs that nobody actually does. > [FP] makes it easier to manage and control state No, not "easier". In fact, incredibly more difficult. Just try updating a nested member. What it does is make it easier to isolate state updates, because it makes it so arduous.
- willtim 9y ago
  > That's kind of the definition of encapsulation. State encapsulation, at least in FP, means that the state is not visible externally. For example a pure function that uses mutable state in its implementation. Such state does not contribute to the sytem global state. > This is repeated as a mantra without any backup. The more global mutable state your application has, the harder it is to reason about. That should be fairly obvious I think.

TimMurnaghan 9y ago

It's cute how people thing that functional will fix everything. In what way does functional make state explicit? If I look at a structure (if you have one in your language) and ask who changes this part of it across a large code base - it's much worse when you've just got a bunch of functions (with bad names) which can be hiding anywhere. And the "reasoned about" shibboleth. What "reasoning" do you actually do. Don't get me wrong - I have a long history in Lisp and ML and they're good languages in which good people can write good software. But no magic bullets. In another part of the development world I've seen React programmers jumping on the functional bandwagon and deciding that all components have to be stateless. Taking the state outside the components means that we have lots of bugs with mistaken state sharing. So external state doesn't equal well-managed.

quickthrower2 9y ago
In functional programming n Haskell functions are pure so there is no state just an input and an output. The exception is the IO entry point. There is a lot of opportunity to sandbox things so that if you know the type of the function you know what it can or can't do to the programs state.

mpweiher 9y ago

> not offer true state encapsulation, it just hides it. That's kind of the definition of encapsulation. > difficult to reason about This is repeated as a mantra without any backup. Most people find state trivial to "reason" about. What becomes more difficult are certain types of proofs that nobody actually does. > [FP] makes it easier to manage and control state No, not "easier". In fact, incredibly more difficult. Just try updating a nested member. What it does is make it easier to isolate state updates, because it makes it so arduous.

willtim 9y ago
> That's kind of the definition of encapsulation. State encapsulation, at least in FP, means that the state is not visible externally. For example a pure function that uses mutable state in its implementation. Such state does not contribute to the sytem global state. > This is repeated as a mantra without any backup. The more global mutable state your application has, the harder it is to reason about. That should be fairly obvious I think.