5 ms·

Agree that Java and C++ are poor examples. However, OOP fundamentally results in a combinatorial explosion of state, which makes programs difficult to reason ab

Agree that Java and C++ are poor examples. However, OOP fundamentally results in a combinatorial explosion of state, which makes programs difficult to reason about. This can be useful in some niche applications but does not make a good general approach. The best part of OOP is arguably its support for first-class modules, but this feature could in theory be added to a functional language. EDIT: the reason why there is an explosion of state is because every object in OOP is potentially stateful. If I build a composite object Z from objects X and Y, the set of possible states Z has is a product of the set of possible states X and Y have.

Ace17 9y ago
The combinatorial explosion of state is only problematic if some parts of your program can actually "see" the global state resulting from the combinations, and thus, depend on some specific combinations in an undesirable way. In this case, you might have a design issue. This is exactly one of the problems encapsulation and abstraction aim to solve, and has nothing to do with OO: you could also create a combinatoric explosion of possible behaviours by dynamically composing pure functions.
- willtim 9y ago
  Any global state is potentially visible externally in terms of the behaviour of your system. Yes pure functions can be complex, but their behaviour is entirely reproducible and testable. For state not to be visible externally, i.e. true state encapsulation, then you need components that appear stateless externally, which is not how most people do OOP.
ktRolster 9y ago
OOP fundamentally results in a combinatorial explosion of state I'd be interested in knowing what theory you are basing this on. In practice, I have never seen this combinatorial explosion of state, but maybe that's just me.
- willtim 9y ago
  Every object in OOP is potentially stateful, some are made stateless and immutable but most are not, you need to read the docs. If I build a composite object Z from objects X and Y, the set of possible states Z has is a product of the set of possible states X and Y have. No complicated theory, just basic mathematics. I spent many years building OOP systems before moving on to FP. I strongly disagree with the claim that it is easy to manage state in OOP!
  - jcelerier 9y ago
    State doesn't magically disappear in FP. It just isn't given a name but it's still here, in your closures.
    - willtim 9y ago
      Functional programming languages do not capture mutable state in closures.
      - jcelerier 9y ago
        So LISP and Caml aren't functional programming language nowadays ? Because both allow you to modify what's in a closure.
        willtim 9y ago
        There is no language definition or implementation called "LISP". Both Scheme and OCaml lexically capture variables by value, as if they have been passed in as arguments. This is not how it works in e.g. Python.
        empthought 9y ago
        Python has had closures exactly the same as Scheme and OCaml since the year 2000. What it lacks is a multiline anonymous function syntax. See PEP 227: https://www.python.org/dev/peps/pep-0227/ https://www.python.org/dev/peps/pep-0227/
gnaritas 9y ago
> However, OOP fundamentally results in a combinatorial explosion of state Eh, no it doesn't. I think you need to expand on that statement because it isn't remotely true in my experience.
- willtim 9y ago
  I've now expanded on that statement. In my experience, working using OOP in large multi-million line codebases, the state issues have proven very true.
  - imtringued 9y ago
    How can you know that without comparing the same programs with a FP version? What if those codebases would become messy even with FP simply because the problem they are trying to solve is difficult? Also in what way does OOP prevent you from writing the code in a FP-style? It doesn't because the concepts FP and OOP are orthogonal.
    - willtim 9y ago
      It is much harder to do functional programming in an OOP language, as one is often fighting the syntax, semantics and various defaults. For example all variables are typically by default mutable, null in every type, libraries and frameworks with pervasive mutable state etc. Granted it has been getting easier as OOP languages have been slowly getting more and more functional features. But it really is easier to favour immutability and composition in a functional-first language.
      - deleted 9y ago
        [deleted]

Ace17 9y ago

The combinatorial explosion of state is only problematic if some parts of your program can actually "see" the global state resulting from the combinations, and thus, depend on some specific combinations in an undesirable way. In this case, you might have a design issue. This is exactly one of the problems encapsulation and abstraction aim to solve, and has nothing to do with OO: you could also create a combinatoric explosion of possible behaviours by dynamically composing pure functions.

willtim 9y ago
Any global state is potentially visible externally in terms of the behaviour of your system. Yes pure functions can be complex, but their behaviour is entirely reproducible and testable. For state not to be visible externally, i.e. true state encapsulation, then you need components that appear stateless externally, which is not how most people do OOP.

ktRolster 9y ago

OOP fundamentally results in a combinatorial explosion of state I'd be interested in knowing what theory you are basing this on. In practice, I have never seen this combinatorial explosion of state, but maybe that's just me.

willtim 9y ago
Every object in OOP is potentially stateful, some are made stateless and immutable but most are not, you need to read the docs. If I build a composite object Z from objects X and Y, the set of possible states Z has is a product of the set of possible states X and Y have. No complicated theory, just basic mathematics. I spent many years building OOP systems before moving on to FP. I strongly disagree with the claim that it is easy to manage state in OOP!
- jcelerier 9y ago
  State doesn't magically disappear in FP. It just isn't given a name but it's still here, in your closures.
  - willtim 9y ago
    Functional programming languages do not capture mutable state in closures.
    - jcelerier 9y ago
      So LISP and Caml aren't functional programming language nowadays ? Because both allow you to modify what's in a closure.
      - willtim 9y ago
        There is no language definition or implementation called "LISP". Both Scheme and OCaml lexically capture variables by value, as if they have been passed in as arguments. This is not how it works in e.g. Python.
        empthought 9y ago
        Python has had closures exactly the same as Scheme and OCaml since the year 2000. What it lacks is a multiline anonymous function syntax. See PEP 227: https://www.python.org/dev/peps/pep-0227/ https://www.python.org/dev/peps/pep-0227/

gnaritas 9y ago

> However, OOP fundamentally results in a combinatorial explosion of state Eh, no it doesn't. I think you need to expand on that statement because it isn't remotely true in my experience.

willtim 9y ago
I've now expanded on that statement. In my experience, working using OOP in large multi-million line codebases, the state issues have proven very true.
- imtringued 9y ago
  How can you know that without comparing the same programs with a FP version? What if those codebases would become messy even with FP simply because the problem they are trying to solve is difficult? Also in what way does OOP prevent you from writing the code in a FP-style? It doesn't because the concepts FP and OOP are orthogonal.
  - willtim 9y ago
    It is much harder to do functional programming in an OOP language, as one is often fighting the syntax, semantics and various defaults. For example all variables are typically by default mutable, null in every type, libraries and frameworks with pervasive mutable state etc. Granted it has been getting easier as OOP languages have been slowly getting more and more functional features. But it really is easier to favour immutability and composition in a functional-first language.
    - deleted 9y ago
      [deleted]