4 ms·

Data is defined by behavior, even for "plain old" types. The point of "objects" is that sometimes you can implement the very same behavior in ways that are ess

Data is defined by behavior, even for "plain old" types. The point of "objects" is that sometimes you can implement the very same behavior in ways that are essentially isomorphic from the POV of your outside code, and want the freedom of switching out the underlying implementation at any time, and perhaps of validating complex invariants about the behavior your object has been designed for-- without letting implementation details dictate what sorts of behaviors you're going expose (the way, e.g. a "record" datatype exposes the equivalent of getters and setters, or a "variant record" exposes pattern matching, etc.). This ("objects-based" programming; or programming with "abstract types") actually works fine. The part where OOP leads to real problems that make it inimical to true modularity is all about the tacked-on features of inheritance and polymorphism; specifically, implementation inheritance. Because that means you've started relying on the very interface you were supposed to define in order to implement some other behaviors implied in it, and then for good measure you're allowing that interface to change in practically arbitrary ways as new "derived" classes are defined. It's not surprising that this fails to work well.

wellpast 7y ago
> Data is defined by behavior, even for "plain old" types. This is the POV of the OOP-ist, but it is not necessary and it is limiting. It's actually the "debate" we are having, so asserting it isn't proving it! Functional programming has a complete story for polymorphism so OOP does not win on that account contrary to what you're implying. I do think we have common ground in shunning class inheritance which is useless and a complete disaster. However even without inheritance it seems to be that "objects" are provably replaceable by functions. (E.g., promote the implicit `this` reference to a first-class reference provided as an explicit arg to functions.) I see no reason why data can't have opaque parts so data encapsulation doesn't seem to be a unique OOP claim either. So then if objects aren't necessary for polymorphism and data encapsulation, then what are they good for?
- 0815test 7y ago
  > This is the POV of the OOP-ist, but it is not necessary and it is limiting. How is it "limiting"? And if you want proof, look at the untyped lambda calculus - there you find data types defined entirely in terms of functions - pure behavior! (For example, the Church natural numbers are defined by the behavior of iterating some arbitrary function exactly n times; the Church booleans by taking two arguments and returning either the first or the second argument (which in turns makes it possible to define if-then-else, a sort of pattern matching); and so on and so forth.) It just so happens that this behavior-focused encoding is enough to express arbitrary programs - which is the opposite of limiting!
  - wellpast 7y ago
    > there you find data types defined entirely in terms of functions - pure behavior! In every programming environment that I am aware of, such data-less functions you describe would be happily deleted without any worry to customers & stakeholders. For example: add : Int -> Int -> Int This may look nice on paper but on a real computer there are bounds to this purity. And anyway my program only becomes useful when actual integers are instantiated and appearing on stacks and the heap. The "data-first" ideas we're discussing here ask one to stop obsessing over the functions and model the data soundly. You'll find any PL will do when operating over sound data expressions. This approach ime brings clarity and power to problem solving. Theory divorced from practice is limiting. This is not a philistinic take, btw -- theory is supremely powerful when applied successfully for outcomes. But the "pure behavior!" you're talking about here seems too excitedly far away from practitioner-space.
- meheleventyone 7y ago
  The fact you can make function like constructs in languages that don’t have them as a first class concept doesn’t mean functions are good for nothing. Likewise objects. If you can see benefits to making object like things in a different paradigm those still hold for paradigms that make objects a first class concept. If you’re asking why use a specific language with that concept over one you can implement similar concepts in then usually the argument is going to be about the ergonomics and expressivity of doing so. Similar arguments were had as functions/procedures crawled out of the primordial ASM soup.
chrisweekly 7y ago
Yeah. It's _classical_ inheritance, in particular, that is typically associated with overly-broad criticisms of "OOP".

wellpast 7y ago

> Data is defined by behavior, even for "plain old" types. This is the POV of the OOP-ist, but it is not necessary and it is limiting. It's actually the "debate" we are having, so asserting it isn't proving it! Functional programming has a complete story for polymorphism so OOP does not win on that account contrary to what you're implying. I do think we have common ground in shunning class inheritance which is useless and a complete disaster. However even without inheritance it seems to be that "objects" are provably replaceable by functions. (E.g., promote the implicit `this` reference to a first-class reference provided as an explicit arg to functions.) I see no reason why data can't have opaque parts so data encapsulation doesn't seem to be a unique OOP claim either. So then if objects aren't necessary for polymorphism and data encapsulation, then what are they good for?

0815test 7y ago
> This is the POV of the OOP-ist, but it is not necessary and it is limiting. How is it "limiting"? And if you want proof, look at the untyped lambda calculus - there you find data types defined entirely in terms of functions - pure behavior! (For example, the Church natural numbers are defined by the behavior of iterating some arbitrary function exactly n times; the Church booleans by taking two arguments and returning either the first or the second argument (which in turns makes it possible to define if-then-else, a sort of pattern matching); and so on and so forth.) It just so happens that this behavior-focused encoding is enough to express arbitrary programs - which is the opposite of limiting!
- wellpast 7y ago
  > there you find data types defined entirely in terms of functions - pure behavior! In every programming environment that I am aware of, such data-less functions you describe would be happily deleted without any worry to customers & stakeholders. For example: add : Int -> Int -> Int This may look nice on paper but on a real computer there are bounds to this purity. And anyway my program only becomes useful when actual integers are instantiated and appearing on stacks and the heap. The "data-first" ideas we're discussing here ask one to stop obsessing over the functions and model the data soundly. You'll find any PL will do when operating over sound data expressions. This approach ime brings clarity and power to problem solving. Theory divorced from practice is limiting. This is not a philistinic take, btw -- theory is supremely powerful when applied successfully for outcomes. But the "pure behavior!" you're talking about here seems too excitedly far away from practitioner-space.
meheleventyone 7y ago
The fact you can make function like constructs in languages that don’t have them as a first class concept doesn’t mean functions are good for nothing. Likewise objects. If you can see benefits to making object like things in a different paradigm those still hold for paradigms that make objects a first class concept. If you’re asking why use a specific language with that concept over one you can implement similar concepts in then usually the argument is going to be about the ergonomics and expressivity of doing so. Similar arguments were had as functions/procedures crawled out of the primordial ASM soup.

chrisweekly 7y ago

Yeah. It's _classical_ inheritance, in particular, that is typically associated with overly-broad criticisms of "OOP".