3 ms·

Yes! Every functional codebase I see seems to be littered with the artifacts of an effort to escape the reality that the known universe and everything that happ

by jtdev 6y ago

Yes! Every functional codebase I see seems to be littered with the artifacts of an effort to escape the reality that the known universe and everything that happens within it is stateful... including our code. It’s inescapable, so why does the FP crowd make state even more difficult to reason about through batshit crazy abstractions? I’m honestly completely baffled by the FP movement and the trend of talking down OOP as some simpleton concept that should be abandoned.

antonvs 6y ago
Nothing in the universe is stateful. You only think otherwise because you impose an object abstraction on things and treat their evolution over time in a non-rigorous way. This lack of proper modeling of the effects of time on a system is what leads to all the problems with managing state. FP makes this relationship of change to time explicit. Instead of having a "single object" that "changes state" when some event occurs, you have two objects - one before the event, one after. Systems that rely on mutable state conflate these two and then force you to deal with the consequences of that conflation.
- goatlover 6y ago
  Does that mean computers aren't stateful? You have one computer before an event and another after?
  - antonvs 6y ago
    Not quite. The computer you're referring to has one state before an event, and another state afterwards. Modeling those as two distinct, immutable states provides enormous benefits over modeling it as a single state that "mutates". Doing this eliminates a large class of serious bugs. The reason for these benefits is that far from trying to "escape the reality that the known universe and everything that happens within it is stateful," functional programming uses a more rigorous model of state that better reflects the relationships between states over time.
    - jtdev 6y ago
      You’re points assume that OOP programs consist of a single god class stuffed full of nothing but mutable properties... which is obviously not sound OOP design.
      - antonvs 6y ago
        It doesn't have to be god classes. Any mutable property that's accessible beyond a local scope raises these issues, and involves the collapsing of state over time. That's not to say it's never valid to make the conscious engineering choice to do that, but it's a poor default to have. Functional programming languages have proved that this can be handled better.
        jtdev 6y ago
        Don’t closures effectively break down this FP facade of local scope only mutability?
        mrkeen 6y ago
        If you're using them to pass around mutable state, yes. Which is why immutable/pure-functional is always the best first choice. If it's inconvenient to do something with pure functions, and you want to pass a bit of state around, you can use the State monad - it's 'simulated' mutable state, in that it's all pure functions under the hood, but it looks and feels like you're doing mutation. If it's too inefficient to simulate state via the State monad, you can use state threads (ST). This is more efficient in that it compiles down to real mutations, but it's safe in that you can't share your mutations until you've exited the ST. So it should force determinism. This is what you'd use for a fast, mutable, in-place sort. The above two solutions rule out having multiple writers, which is where STM (software transactional memory comes in). STM gives you atomic blocks which behave more or less like (in-memory) database transactions. I mainly use it for implementing workers and jobs and queues, etc. And if you actually just want to do anything then you use IO. It's more about being aware (in a compiler-checkable way) whether you're mutating or not than it is about outlawing mutation.
mrkeen 6y ago
> everything that happens within it is stateful If that were the case I'd just fix your comment instead of appending another comment after the fact. But that would make the arguments harder to reason about I think. > including our code Do you use git? Or does your team all just edit the same code on a shared server? (The OO solution here is to make state 'private'. It supposedly doesn't really matter than you're all editing the same documents at the same time, because they're behind getters and setters) > why does the FP crowd make state even more difficult to reason about? State is difficult to reason about so we maximise out stateless code. > talking down OOP I talk down OOP when I treat it as the diff between OOP and FP. That is, coding is 80+% the same whatever you use. It's the last 10-20% where the differences emerge: Lambdas are better than anonymous inner classes. Not having null is better than having null. Not needing to cast is better than casting. Composition is better than inheritance. Stateless is better than stateful. Value-equality is better than reference-equality. Generics + type erasure is clunky without higher-kinded types.
- spankalee 6y ago
  > The OO solution here is to make state 'private'. It supposedly doesn't really matter than you're all editing the same documents at the same time, because they're behind getters and setters This just isn't true in the slightest sense. Honestly, where does this kind of anti-OOP trope come from?
  - mrkeen 6y ago
    It isn't a direct bashing of OOP. It's a bashing of the claim (see wiki quote) that you can make state manipulation safe by hiding it away inside a class. Encapsulation Encapsulation is an object-oriented programming concept that binds together the data and functions that manipulate the data, and that keeps both safe from outside interference and misuse. Data encapsulation led to the important OOP concept of data hiding. It's arguably the core concept of OO, and I don't believe it keeps data 'safe from outside interference and misuse'.
    - jtdev 6y ago

by jtdev 6y ago

antonvs 6y ago

Nothing in the universe is stateful. You only think otherwise because you impose an object abstraction on things and treat their evolution over time in a non-rigorous way. This lack of proper modeling of the effects of time on a system is what leads to all the problems with managing state. FP makes this relationship of change to time explicit. Instead of having a "single object" that "changes state" when some event occurs, you have two objects - one before the event, one after. Systems that rely on mutable state conflate these two and then force you to deal with the consequences of that conflation.

goatlover 6y ago
Does that mean computers aren't stateful? You have one computer before an event and another after?
- antonvs 6y ago
  Not quite. The computer you're referring to has one state before an event, and another state afterwards. Modeling those as two distinct, immutable states provides enormous benefits over modeling it as a single state that "mutates". Doing this eliminates a large class of serious bugs. The reason for these benefits is that far from trying to "escape the reality that the known universe and everything that happens within it is stateful," functional programming uses a more rigorous model of state that better reflects the relationships between states over time.
  - jtdev 6y ago
    You’re points assume that OOP programs consist of a single god class stuffed full of nothing but mutable properties... which is obviously not sound OOP design.
    - antonvs 6y ago
      It doesn't have to be god classes. Any mutable property that's accessible beyond a local scope raises these issues, and involves the collapsing of state over time. That's not to say it's never valid to make the conscious engineering choice to do that, but it's a poor default to have. Functional programming languages have proved that this can be handled better.
      - jtdev 6y ago
        Don’t closures effectively break down this FP facade of local scope only mutability?
        mrkeen 6y ago
        If you're using them to pass around mutable state, yes. Which is why immutable/pure-functional is always the best first choice. If it's inconvenient to do something with pure functions, and you want to pass a bit of state around, you can use the State monad - it's 'simulated' mutable state, in that it's all pure functions under the hood, but it looks and feels like you're doing mutation. If it's too inefficient to simulate state via the State monad, you can use state threads (ST). This is more efficient in that it compiles down to real mutations, but it's safe in that you can't share your mutations until you've exited the ST. So it should force determinism. This is what you'd use for a fast, mutable, in-place sort. The above two solutions rule out having multiple writers, which is where STM (software transactional memory comes in). STM gives you atomic blocks which behave more or less like (in-memory) database transactions. I mainly use it for implementing workers and jobs and queues, etc. And if you actually just want to do anything then you use IO. It's more about being aware (in a compiler-checkable way) whether you're mutating or not than it is about outlawing mutation.

mrkeen 6y ago

> everything that happens within it is stateful If that were the case I'd just fix your comment instead of appending another comment after the fact. But that would make the arguments harder to reason about I think. > including our code Do you use git? Or does your team all just edit the same code on a shared server? (The OO solution here is to make state 'private'. It supposedly doesn't really matter than you're all editing the same documents at the same time, because they're behind getters and setters) > why does the FP crowd make state even more difficult to reason about? State is difficult to reason about so we maximise out stateless code. > talking down OOP I talk down OOP when I treat it as the diff between OOP and FP. That is, coding is 80+% the same whatever you use. It's the last 10-20% where the differences emerge: Lambdas are better than anonymous inner classes. Not having null is better than having null. Not needing to cast is better than casting. Composition is better than inheritance. Stateless is better than stateful. Value-equality is better than reference-equality. Generics + type erasure is clunky without higher-kinded types.

spankalee 6y ago
> The OO solution here is to make state 'private'. It supposedly doesn't really matter than you're all editing the same documents at the same time, because they're behind getters and setters This just isn't true in the slightest sense. Honestly, where does this kind of anti-OOP trope come from?
- mrkeen 6y ago
  It isn't a direct bashing of OOP. It's a bashing of the claim (see wiki quote) that you can make state manipulation safe by hiding it away inside a class. Encapsulation Encapsulation is an object-oriented programming concept that binds together the data and functions that manipulate the data, and that keeps both safe from outside interference and misuse. Data encapsulation led to the important OOP concept of data hiding. It's arguably the core concept of OO, and I don't believe it keeps data 'safe from outside interference and misuse'.
  - jtdev 6y ago