5 ms·

It's true that functional programming also doesn't have a formal definition, but I wouldn't say it's "exactly the same" as with OOP. Functional programming is b

It's true that functional programming also doesn't have a formal definition, but I wouldn't say it's "exactly the same" as with OOP. Functional programming is based on a simple well-understood mathematical model: lambda calculus. While there are different flavors of lambda calculus, they are related in obvious ways and one can reach formal conclusions them as a whole, e.g., the Church-Rosser theorem. In contrast, the many attempts to formalize the essence of OOP have resulted in countless wildly different results, so it's impossible to say anything meaningful about OOP, with the possible exception of this sentence.

ebingdom 5y ago
To all the people downvoting me: if you really think OOP is as well understood as FP, learn some programming language theory. Tell me what the universally agreed foundation of OOP is. You won't be able to, but I can tell for FP it's lambda calculus.
- jasperry 5y ago
  I agree that functional programming has a more widely agreed-upon foundational set of definitions than OOP. However, it doesn't follow from that that "it's impossible to say anything meaningful about OOP".
- slver 5y ago
  > Tell me what the universally agreed foundation of OOP is. I'll deliberately avoid terms so we don't get to argue about words, but rather substance. 1. Objects have identity that's independent of their state (two objects with same state are still distinct). 2. Objects contain implementation which is hidden, including optionally mutable state. 3. Communication occurs through handlers/methods/calls, which provide only INDIRECT access to the object's internal state. 4. Objects can stand for one another, if their handlers react in a compatible way with the object they're replacing. I tried to keep it as basic as possible, while avoiding topics about inheritance and what not. Now the question is "do you need an OOP language to do OOP", and no, you don't. There's overlap. For example if you take the above, you'll notice that closures in FP match all of those except one thing: mutable state. So if your FP language allows mutable state, then you can do OOP in it with closures. And that's not a proof that OOP is not a thing, rather it's a proof that what some small minds keep putting in opposition, things like FP vs OOP vs DOP are just pieces of a larger puzzle that forms a single cohesive picture.
  - valenterry 5y ago
    Doesn't 4 contradict 1? Or do you mean "can stand for one another in a certain context". That would be rather weak criteria then though.
    - deleted 5y ago
      [deleted]
    - slver 5y ago
      1 is about object identity. 4 is about object type/function. I.e. polymorphism. It may seem like a weak criteria if you're using to OOP/FP languages that provide typesafe, efficient polymorphism out of the box. But the reason we have Obj C and C++ is that polymorphism (while also maintaining encapsulation etc.) is a living nightmare in a language like C.

ebingdom 5y ago

To all the people downvoting me: if you really think OOP is as well understood as FP, learn some programming language theory. Tell me what the universally agreed foundation of OOP is. You won't be able to, but I can tell for FP it's lambda calculus.

jasperry 5y ago
I agree that functional programming has a more widely agreed-upon foundational set of definitions than OOP. However, it doesn't follow from that that "it's impossible to say anything meaningful about OOP".
slver 5y ago
> Tell me what the universally agreed foundation of OOP is. I'll deliberately avoid terms so we don't get to argue about words, but rather substance. 1. Objects have identity that's independent of their state (two objects with same state are still distinct). 2. Objects contain implementation which is hidden, including optionally mutable state. 3. Communication occurs through handlers/methods/calls, which provide only INDIRECT access to the object's internal state. 4. Objects can stand for one another, if their handlers react in a compatible way with the object they're replacing. I tried to keep it as basic as possible, while avoiding topics about inheritance and what not. Now the question is "do you need an OOP language to do OOP", and no, you don't. There's overlap. For example if you take the above, you'll notice that closures in FP match all of those except one thing: mutable state. So if your FP language allows mutable state, then you can do OOP in it with closures. And that's not a proof that OOP is not a thing, rather it's a proof that what some small minds keep putting in opposition, things like FP vs OOP vs DOP are just pieces of a larger puzzle that forms a single cohesive picture.
- valenterry 5y ago
  Doesn't 4 contradict 1? Or do you mean "can stand for one another in a certain context". That would be rather weak criteria then though.
  - deleted 5y ago
    [deleted]
  - slver 5y ago
    1 is about object identity. 4 is about object type/function. I.e. polymorphism. It may seem like a weak criteria if you're using to OOP/FP languages that provide typesafe, efficient polymorphism out of the box. But the reason we have Obj C and C++ is that polymorphism (while also maintaining encapsulation etc.) is a living nightmare in a language like C.