5 ms·

The start of the article is a very compelling description of why you should split your code into smaller components instead of just having a single structured p

by kace91 7y ago

The start of the article is a very compelling description of why you should split your code into smaller components instead of just having a single structured procedure. Levels of abstraction, testability, etc. - Pretty basic stuff I think. I don't know where he took the leap to consider objects those components though. You can perfectly expose a function that is internally split without making it public in the public interface. And you certainly don't want to deal with the extra problems of having shared state... Object-oriented is not an antonym of monolithic. In fact, I'd say they tend to end up being related terms, rather than opposed.

Sharlin 7y ago
The justification for shared state that the author presents is that threading a lot of (mutable) state as parameters through a tree of SRP-obeying internal functions gets unwieldy. Factoring that state into the fields of a class and making those functions methods is, of course, the ”obvious” solution when you’re thinking inside OOP box. It is also completely isomorphic to the obvious imperative solution of factoring the state into a struct/record and passing that around. Both approaches have the same problem of being based on mutable state. The obvious solution to a functional programmer is to make the state immutable and make the functions return the new state instead of modifying it in place. Furthermore, each function should only take the state it actually needs. Of course, this doesn’t really help with the unwieldiness, especially in a language without helpers such as the Clojure `->` threading macro, or a reasonable lens library (and lenses themselves are not the most obvious abstraction ever), so I guess YMMV. But getting rid of mutable state is often a win anyway.
- BubRoss 7y ago
  If state is immutable, then it's constant data, not state.
  - Sharlin 7y ago
    Au contraire! Languages with no mutation at all, like Haskell, still have a well-defined concept of state. If anything, it's more well-defined than in imperative languages based on side effects. I refer you to Rich Hickey's "Values and Change: Clojure’s approach to Identity and State" [1]. [1] https://clojure.org/about/state https://clojure.org/about/state
    - BubRoss 7y ago
      Those are both just hiding mutation and copying.
MauranKilom 7y ago
The jump happens when you have parameter lists too long to fit on the screen. In C++ terms, consider a const member function that returns something - you know that it can use all the members (without having to explicitly specify each one as parameter) but not change them, so the only "mutation" it can perform is constrained to the return value (ignoring aspects like const not being transitive for pointer members). In practice I still think this doesn't work on complex algorithms because it remains unclear what depends on what.

by kace91 7y ago

Sharlin 7y ago

The justification for shared state that the author presents is that threading a lot of (mutable) state as parameters through a tree of SRP-obeying internal functions gets unwieldy. Factoring that state into the fields of a class and making those functions methods is, of course, the ”obvious” solution when you’re thinking inside OOP box. It is also completely isomorphic to the obvious imperative solution of factoring the state into a struct/record and passing that around. Both approaches have the same problem of being based on mutable state. The obvious solution to a functional programmer is to make the state immutable and make the functions return the new state instead of modifying it in place. Furthermore, each function should only take the state it actually needs. Of course, this doesn’t really help with the unwieldiness, especially in a language without helpers such as the Clojure `->` threading macro, or a reasonable lens library (and lenses themselves are not the most obvious abstraction ever), so I guess YMMV. But getting rid of mutable state is often a win anyway.

BubRoss 7y ago
If state is immutable, then it's constant data, not state.
- Sharlin 7y ago
  Au contraire! Languages with no mutation at all, like Haskell, still have a well-defined concept of state. If anything, it's more well-defined than in imperative languages based on side effects. I refer you to Rich Hickey's "Values and Change: Clojure’s approach to Identity and State" [1]. [1] https://clojure.org/about/state https://clojure.org/about/state
  - BubRoss 7y ago
    Those are both just hiding mutation and copying.

MauranKilom 7y ago

The jump happens when you have parameter lists too long to fit on the screen. In C++ terms, consider a const member function that returns something - you know that it can use all the members (without having to explicitly specify each one as parameter) but not change them, so the only "mutation" it can perform is constrained to the return value (ignoring aspects like const not being transitive for pointer members). In practice I still think this doesn't work on complex algorithms because it remains unclear what depends on what.