> 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 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.
It’s fine. My honest interpretation of it is that you’re not well informed. But I gave you the benefit of the doubt thinking that maybe I can learn more in case you actually knew what you’re talking about.
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-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.