3 ms·

> avoid coupling logic and state as much as possible period depending on how you define "state". In OOP, the coupling is between a bunch of transitions (as a s

by nsonha 2y ago

> avoid coupling logic and state as much as possible period depending on how you define "state". In OOP, the coupling is between a bunch of transitions (as a single class) to a bunch of states (as a single type). It's actually *loose* coupling that is the problem here because that set-up can easily produce invalid states. It can be addressed with the builder pattern. Tight coupling is a problem alright, no one is denying that. It's just there is nothing wrong conceptually about "coupling state to the logic", that is a non-problem, and "tight coupling" has never meant that.

ninetyninenine 2y ago
Highly disagree state to logic is a huge problem. Once you couple state and logic together you lose modularity so such couplings need to be avoided. The reason is as I said. Once state and logic are coupled it becomes entangled with all the logic related to the same state. What you’re referring to is a transaction. Where multiple states must be changed at the same time as a transaction. And while you don’t explicitly say it you’re implying that transactions are required. They can’t be avoided. And that’s where I agree. Coupling state and logic is a problem and must be avoided as much as possible, but you can’t fully avoid it. The main problem with oop is that it promotes the coupling of state and logic everywhere. The style of programming maximizes tight coupling all over the place. That is the problem and the insight you’re not seeing. Years of doing oop makes you feel that such couplings can’t be minimized. This makes oop highly unmodular. It makes it so that refactoring a of code are normal almost every time a new feature is introduced. If you want more insight into what I’m talking about you can follow some of the branching threads that I’m in where I write examples and maybe you’ll see what I’m talking about.
- nsonha 2y ago
  no one is talking about transaction. I'm talking about state machine which is what most program boils down to. The problem with OOP is, AGAIN that all states are lumped together in a single type (class) and so are all the state transitions (methods). This IS a problem, but it is not "tight coupling". "Tight coupling" has a known meaning and refers to relationship between components/classes, see what people mean by it in this thread. I can simply just repeat that the situation here is actually *loose* coupling, because in order to correctly model state machine, you need to further break down the class into individual states (states not properties, I feel like you need to be noted this distinction) and attribute only the relevant states transitions/methods to each of them, making the coupling of the logic and the state even tighter. Functional programming is the same, in a strong type system, which they often have, you can't pass input of this function to another. The solution to that is you write more unixy functions that take more generic types. But for high-level, domain-related functions, this coupling is what you actually want. We can disagree on whether "coupling state to logic is a huge problem". My original point is that it's an entire other thing not the particular "tight coupling" that is the downside of OOP, as widely discussed.
  - ninetyninenine 2y ago
    > no one is talking about transaction. I'm talking about state machine which is what most program boils down to. A transaction is an operation on a state machine in the form you yourself described below: > depending on how you define "state". In OOP, the coupling is between a bunch of transitions (as a single class) to a bunch of states (as a single type). The bunch of transitions on a bunch of state is a “transaction” > "Tight coupling" has a known meaning and refers to relationship between components/classes, see what people mean by it in this thread. Tight coupling does not mean that. See the generalized response from ChatGPT: https://chatgpt.com/share/6719060e-9e8c-8001-bdf9-79502712c114 https://chatgpt.com/share/6719060e-9e8c-8001-bdf9-79502712c1... Tight coupling encompasses the relationship between components and classes but it has a more generalized meaning illustrated in the link above. > I can simply just repeat that the situation here is actually loose coupling, because in order to correctly model state machine, you need to further break down the class into individual states (states not properties, I feel like you need to be noted this distinction) and attribute only the relevant states transitions/methods to each of them, making the coupling of the logic and the state even tighter. Not clear what you’re saying here. State on classes does come in the form of properties. They are the same in my mind. Please illustrate the distinction. Also what do you mean by break it down? And how does breaking it down make coupling tighter? Are you saying if class A has two properties, say two ints x and y whose state changes need to happen at the same and if I break down x and y into individual classes then to ensure that changes on x and y happen at the same time I have to use object composition and have x and y owned by a third even bigger class and this is the “tighter coupling” you’re talking about that is ironically caused by “loosely coupling” x and y into separate classes? Functional programming doesn’t address this if this is what you’re talking about. Functional programming addresses the coupling between method and state. Coupling between state and state isn’t an issue in Fp because everything is immutable. Why don’t you write some pseudo code so I can better understand what you’re addressing? I was going to do it but I want to be sure about what you’re talking about. > Functional programming is the same, in a strong type system, which they often have, you can't pass input of this function to another. The solution to that is you write more unixy functions that take more generic types. But for high-level, domain-related functions, this coupling is what you actually want. Again not clear. You talk about state machines then you say Fp is the same when Fp doesn’t have a state machine. Fp is all about writing functions that declare the entire state in one go. > I'm talking about state machine which is what most program boils down to. In Fp, the state machine is abstracted away from the program so not sure how this relates? State change is a problem that can’t fully go away but it’s segregated from your code as much as possible in Fp. Perhaps you should illustrate your point with pseudocode because at this point there could be a number of issues we aren’t seeing eye to eye on some of which may only be related to communication.

by nsonha 2y ago

ninetyninenine 2y ago

Highly disagree state to logic is a huge problem. Once you couple state and logic together you lose modularity so such couplings need to be avoided. The reason is as I said. Once state and logic are coupled it becomes entangled with all the logic related to the same state. What you’re referring to is a transaction. Where multiple states must be changed at the same time as a transaction. And while you don’t explicitly say it you’re implying that transactions are required. They can’t be avoided. And that’s where I agree. Coupling state and logic is a problem and must be avoided as much as possible, but you can’t fully avoid it. The main problem with oop is that it promotes the coupling of state and logic everywhere. The style of programming maximizes tight coupling all over the place. That is the problem and the insight you’re not seeing. Years of doing oop makes you feel that such couplings can’t be minimized. This makes oop highly unmodular. It makes it so that refactoring a of code are normal almost every time a new feature is introduced. If you want more insight into what I’m talking about you can follow some of the branching threads that I’m in where I write examples and maybe you’ll see what I’m talking about.

nsonha 2y ago
no one is talking about transaction. I'm talking about state machine which is what most program boils down to. The problem with OOP is, AGAIN that all states are lumped together in a single type (class) and so are all the state transitions (methods). This IS a problem, but it is not "tight coupling". "Tight coupling" has a known meaning and refers to relationship between components/classes, see what people mean by it in this thread. I can simply just repeat that the situation here is actually *loose* coupling, because in order to correctly model state machine, you need to further break down the class into individual states (states not properties, I feel like you need to be noted this distinction) and attribute only the relevant states transitions/methods to each of them, making the coupling of the logic and the state even tighter. Functional programming is the same, in a strong type system, which they often have, you can't pass input of this function to another. The solution to that is you write more unixy functions that take more generic types. But for high-level, domain-related functions, this coupling is what you actually want. We can disagree on whether "coupling state to logic is a huge problem". My original point is that it's an entire other thing not the particular "tight coupling" that is the downside of OOP, as widely discussed.
- ninetyninenine 2y ago
  > no one is talking about transaction. I'm talking about state machine which is what most program boils down to. A transaction is an operation on a state machine in the form you yourself described below: > depending on how you define "state". In OOP, the coupling is between a bunch of transitions (as a single class) to a bunch of states (as a single type). The bunch of transitions on a bunch of state is a “transaction” > "Tight coupling" has a known meaning and refers to relationship between components/classes, see what people mean by it in this thread. Tight coupling does not mean that. See the generalized response from ChatGPT: https://chatgpt.com/share/6719060e-9e8c-8001-bdf9-79502712c114 https://chatgpt.com/share/6719060e-9e8c-8001-bdf9-79502712c1... Tight coupling encompasses the relationship between components and classes but it has a more generalized meaning illustrated in the link above. > I can simply just repeat that the situation here is actually loose coupling, because in order to correctly model state machine, you need to further break down the class into individual states (states not properties, I feel like you need to be noted this distinction) and attribute only the relevant states transitions/methods to each of them, making the coupling of the logic and the state even tighter. Not clear what you’re saying here. State on classes does come in the form of properties. They are the same in my mind. Please illustrate the distinction. Also what do you mean by break it down? And how does breaking it down make coupling tighter? Are you saying if class A has two properties, say two ints x and y whose state changes need to happen at the same and if I break down x and y into individual classes then to ensure that changes on x and y happen at the same time I have to use object composition and have x and y owned by a third even bigger class and this is the “tighter coupling” you’re talking about that is ironically caused by “loosely coupling” x and y into separate classes? Functional programming doesn’t address this if this is what you’re talking about. Functional programming addresses the coupling between method and state. Coupling between state and state isn’t an issue in Fp because everything is immutable. Why don’t you write some pseudo code so I can better understand what you’re addressing? I was going to do it but I want to be sure about what you’re talking about. > Functional programming is the same, in a strong type system, which they often have, you can't pass input of this function to another. The solution to that is you write more unixy functions that take more generic types. But for high-level, domain-related functions, this coupling is what you actually want. Again not clear. You talk about state machines then you say Fp is the same when Fp doesn’t have a state machine. Fp is all about writing functions that declare the entire state in one go. > I'm talking about state machine which is what most program boils down to. In Fp, the state machine is abstracted away from the program so not sure how this relates? State change is a problem that can’t fully go away but it’s segregated from your code as much as possible in Fp. Perhaps you should illustrate your point with pseudocode because at this point there could be a number of issues we aren’t seeing eye to eye on some of which may only be related to communication.