5 ms·

What is the natural mathematical abstraction to describe object oriented programming? I always feel object oriented languages are some sort of poor approximatio

by foxes 6y ago

What is the natural mathematical abstraction to describe object oriented programming? I always feel object oriented languages are some sort of poor approximation to some sophisticated functional programming concepts (lenses, comonads, etc), or havent realised what they are actually describing. Theres things that in practice feel very similar and some ideas that look dual (some sort or co algebra?).

loopz 6y ago
Whiteboard. Really, OO was meant to mimic whiteboard drawing and being able to convey meaning to stakeholders in a playful and communicative manner. So messaging and what objects do is central. Objects themselves are black boxes left to actual implementation. Design patterns breaks OO heritage. This is opposed to datamodelling, which is the better approach to actually implementing complex stateful systems.
- sgt101 6y ago
  >Design patterns breaks OO heritage. I can't see how - the idea of using patterns was that they would provide a common language of design and a "best practice" for common situations that would allow easier consumption of the services provided by other developers. Seems pretty aligned with OO to me!
  - loopz 6y ago
    This in the context of OO used as communication model with non-developer stakeholders.
danidiaz 6y ago
There are indeed "coalgebraic" descriptions of OOP. - "Objects and Classes, Coalgebraically" (1995) http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.6018 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.6... - "Codata in action" (2019) https://www.microsoft.com/en-us/research/publication/codata-in-action/ https://www.microsoft.com/en-us/research/publication/codata-... Coalgebras fit very well with the "hidden internal state" that characterizes objects in OOP.
Rochus 6y ago
You might be interesten in "A Theory of Objects" by Cardelli et al. (see https://www.amazon.com/-/de/dp/0387947752 https://www.amazon.com/-/de/dp/0387947752).
curryhoward 6y ago
There is a recent paper called "Codata in action" [1] that I think gives a nice explanation of (part of) OOP in terms of codata types. But that paper also finally clarified for me why OOP is so awkward and unnatural sometimes. Why should an entire program be composed only of codata types? One would think data types (which are traditionally seen more in functional languages than OOP languages) would be more natural for most problems. The specific combination of late binding and equi-recursive codata types that is approximated by OOP only makes sense when you're solving a problem that is naturally expressed in terms of those features, but in my mind the majority of problems are not. The other major problem I have with OOP is that it's not a straightforward manifestation of an underlying mathematical calculus, but rather a hodgepodge of (not universally agreed upon) programming ideas that are best applied on a more à la carte basis. These ideas should be used when appropriate rather than taken as an indivisible paradigm to be applied wholesale to every programming problem. That's why I prefer to think of OOP as a design pattern rather than a programming paradigm: useful in some situations, but not to be used for every situation. [1] https://www.microsoft.com/en-us/research/uploads/prod/2020/01/CoDataInAction.pdf https://www.microsoft.com/en-us/research/uploads/prod/2020/0...
- pron 6y ago
  > OOP only makes sense when you're solving a problem that is naturally expressed in terms of those features, but in my mind the majority of problems are not. How do you reach the conclusion that "the majority of problems are not"? But more importantly, the right question is not about the majority of problems, but the most common tricky parts of software, or, more precisely reduce the effort where it is largest, and the majority of tasks does not comprise the majority of effort. I am skeptical about any programming paradigm making a big difference, largely because evidence suggests none so far does, or, at least, that there are diminishing returns, but even if some programming paradigm could make a difference, I doubt FP would be it, and not only because empirically FP so far hasn't. The reason is that FP "helps" when the task is easy to begin with, and once you start dealing with interaction, it "devolves" into classical imperative programming. If any style could help, it would be a style that specifically helps with the hard parts, not the easy parts. An example of a more radical approach would be synchronous programming, that at least aims to make interaction/concurrency easier.
pron 6y ago
> I always feel object oriented languages are some sort of poor approximation to some sophisticated functional programming concepts (lenses, comonads, etc) Even if they were, I don't see why it matters. The nature of the basic mathematical building blocks doesn't have much of an impact when the problem described is intractable to begin with. Not a very good example, but the n-body problem is just as intractable, and no easier to simulate, using Newtonian mechanics than when using epicycles (well, it is, but not because Newtonian mechanics is more mathematically simple). My point is just that when dealing with intractable systems, simplifying the basic mathematical building blocks is not necessarily where we should spend our optimisation efforts.

by foxes 6y ago

loopz 6y ago

Whiteboard. Really, OO was meant to mimic whiteboard drawing and being able to convey meaning to stakeholders in a playful and communicative manner. So messaging and what objects do is central. Objects themselves are black boxes left to actual implementation. Design patterns breaks OO heritage. This is opposed to datamodelling, which is the better approach to actually implementing complex stateful systems.

sgt101 6y ago
>Design patterns breaks OO heritage. I can't see how - the idea of using patterns was that they would provide a common language of design and a "best practice" for common situations that would allow easier consumption of the services provided by other developers. Seems pretty aligned with OO to me!
- loopz 6y ago
  This in the context of OO used as communication model with non-developer stakeholders.

danidiaz 6y ago

There are indeed "coalgebraic" descriptions of OOP. - "Objects and Classes, Coalgebraically" (1995) http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.6018 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.6... - "Codata in action" (2019) https://www.microsoft.com/en-us/research/publication/codata-in-action/ https://www.microsoft.com/en-us/research/publication/codata-... Coalgebras fit very well with the "hidden internal state" that characterizes objects in OOP.

Rochus 6y ago

You might be interesten in "A Theory of Objects" by Cardelli et al. (see https://www.amazon.com/-/de/dp/0387947752 https://www.amazon.com/-/de/dp/0387947752).

curryhoward 6y ago

There is a recent paper called "Codata in action" [1] that I think gives a nice explanation of (part of) OOP in terms of codata types. But that paper also finally clarified for me why OOP is so awkward and unnatural sometimes. Why should an entire program be composed only of codata types? One would think data types (which are traditionally seen more in functional languages than OOP languages) would be more natural for most problems. The specific combination of late binding and equi-recursive codata types that is approximated by OOP only makes sense when you're solving a problem that is naturally expressed in terms of those features, but in my mind the majority of problems are not. The other major problem I have with OOP is that it's not a straightforward manifestation of an underlying mathematical calculus, but rather a hodgepodge of (not universally agreed upon) programming ideas that are best applied on a more à la carte basis. These ideas should be used when appropriate rather than taken as an indivisible paradigm to be applied wholesale to every programming problem. That's why I prefer to think of OOP as a design pattern rather than a programming paradigm: useful in some situations, but not to be used for every situation. [1] https://www.microsoft.com/en-us/research/uploads/prod/2020/01/CoDataInAction.pdf https://www.microsoft.com/en-us/research/uploads/prod/2020/0...

pron 6y ago
> OOP only makes sense when you're solving a problem that is naturally expressed in terms of those features, but in my mind the majority of problems are not. How do you reach the conclusion that "the majority of problems are not"? But more importantly, the right question is not about the majority of problems, but the most common tricky parts of software, or, more precisely reduce the effort where it is largest, and the majority of tasks does not comprise the majority of effort. I am skeptical about any programming paradigm making a big difference, largely because evidence suggests none so far does, or, at least, that there are diminishing returns, but even if some programming paradigm could make a difference, I doubt FP would be it, and not only because empirically FP so far hasn't. The reason is that FP "helps" when the task is easy to begin with, and once you start dealing with interaction, it "devolves" into classical imperative programming. If any style could help, it would be a style that specifically helps with the hard parts, not the easy parts. An example of a more radical approach would be synchronous programming, that at least aims to make interaction/concurrency easier.

pron 6y ago

> I always feel object oriented languages are some sort of poor approximation to some sophisticated functional programming concepts (lenses, comonads, etc) Even if they were, I don't see why it matters. The nature of the basic mathematical building blocks doesn't have much of an impact when the problem described is intractable to begin with. Not a very good example, but the n-body problem is just as intractable, and no easier to simulate, using Newtonian mechanics than when using epicycles (well, it is, but not because Newtonian mechanics is more mathematically simple). My point is just that when dealing with intractable systems, simplifying the basic mathematical building blocks is not necessarily where we should spend our optimisation efforts.