6 ms·

I think this description of what OO is, is flawed and makes people talk past each other: > • What is OO programming? – a programming paradigm that uses "object

by hurril 3y ago

I think this description of what OO is, is flawed and makes people talk past each other: > • What is OO programming? – a programming paradigm that uses "objects" – data structures consisting of datafields and methods together with their interactions – to design applications and computer programs. (Wikipedia) It isn't that they are together, it's that the core entity of the language used to express solutions centers around identity over state or values. As in: two objects are different even when the fields are all equal, and also: two objects can be the same even with different field values. If you are going to object to this, I ask that you first contemplate whether or not you have programmed in any other way first, because as a fish, reasoning about what water is can be difficult.

kragen 3y ago
i am going to object to this; i've programmed in, among other things, prolog, ocaml, basic-80, c, the unadorned λ-calculus, bicicleta, and qfitzah, the last two of which are languages i designed and implemented myself and which have no mutability. moreover i don't think anyone would claim that basic-80 or c is object-oriented so i feel secure in claiming that i am more a walrus than a fish and therefore qualified to opine about water i do agree that identity and hidden mutability are important aspects of the oo view of the world, and that the author of these slides is off-base about what oo is. but i think that the essence of oo is that computation is done by sending messages to objects, but sending the same message to different objects invokes different code. this feature is present without mutability in bicicleta, and in abadi and cardelli's untyped ς-calculus, which it's based on; the ς-calculus was invented to formalize the essence of object-oriented typing the original intuition behind oo was to decompose a computer system into smaller computer systems, like a computer network; each object in the system was in effect a tiny computer, with its own private code and state. this was inspired by alan kay's undergraduate degree in biology, which mostly studies organisms made out of cells, which are basically tiny organisms. and in that formulation, obviously hidden mutability is the default, because you can't prevent a computer from changing its internal state as a result of a packet you send it; and mutability generally means identity is important but even more central to this formulation is the idea that different objects can behave differently in the same circumstances obviously none of this has anything to do with memory layout! except very indirectly
- bruce343434 3y ago
  This is it. OOP is about building sub programs with their own state and behaviours, yet implementing a common interface so they can still effectively communicate to each other. If you boil it down to the essence, this means branching logic is encoded via a function pointer. Instead of manually switching to the correct behavior using other branching mechanisms like if or switch. This is what polymorphism is about. It's pattern matching. An interface is like an Enum to which you can add entries after it has been defined, and the behaviour for that specific variant naturally then has to be encoded inside the variant itself.
  - Gehinnn 3y ago
    Would it be far fetched to say object oriented programming is inspired by nature/physics? And thus, "more natural" than, let's say, procedural programming. Animals can be modeled nicely with objects/classes. Physical objects do have internal private state and public interfaces. Also in nature, usually, you have multiple similar objects that work the same but have different internal state.
    - bruce343434 3y ago
      That might have been what Alan Kay was going for with his "cells of an organism" thing, yes. But even if you're not inspired by biology, it might just come up "naturally". Separating your data into structs, then operations on those structs, and not wanting to deal with all kinds of bookkeeping all the time, letting things manage their own - separation of concerns, aka single responsibility principle. I think automatic memory management might be a big example of this. Who wants to bother with this malloc/free stuff all the time? Who wants to keep track of ownership everywhere? Instead, have a dedicated subsystem handle it. That allows a higher signal to noise ratio in all the rest of the code that would otherwise be polluted with malloc/free. It also removes the entire class of bugs that can happen when you inevitably forget either of those. But having memory management in and of itself isn't "OOP". It's just an example of one of the principles that people tout when they talk of "OOP". Those principles can and do apply broadly. Was Alan Kay thinking of all this? I really don't know. All I know is that the dude digs biology.
cmrdporcupine 3y ago
You've hit the nail on the head, and I think the replies below aren't getting your original point. Which I think is actually your point :-) The defining feature of OO approaches is in shifting the emphasis in sw development into the concept of identity-bags. All the other stuff about message passing, encapsulation, inheritance etc is just window dressing and implementation details of this core concept of identity-classification in software systems. I like how the "Out Of the Tarpit" (2006) paper breaks this down into the notion of "intentional" vs "extensional" identity, and I think this is a great model. For them, OO is all about "intentional identity" in that we create identities (objects, components) in our systems and move attributes and behavior onto them. OO shifts the analysis of software to identifying objects, components, services, and then makes software development all about the taxonomical management of them. In this model of software development, it's all about identifying components and then shuffling the data and functionality "into" them and managing the flow between them. (FWIW the paper identifies this way of thinking as one of the prime culprits in unnecessary complexity in software systems, and I agree with them.) The contrast is "extensional" identity, where identity in the software systems are emergent from their attributes. In this box we can put the relational data model, and its cousins in logic programming (prolog, datalog etc). In those systems, we are not concerned with "creating" identities and classifying systems/components/objects, but instead declaring the raw attributes -- tuples, facts, relations -- only. Queries then produce, at runtime, a multitude of results from permutations of those attributes. And, as you point out, equality/inequality is defined by the value of a tuples attributes, not by the object it lies in. This is crucial. There's a couple generations of software developers that are so immersed in the OO/intentional-identity way of thinking that they don't see that it's not intrinsic to software development, but actually a mental framework that was fostered through the 80s and 90s. It was an attempt to manage complexity and structure in software systems and also to create a marketplace of re-usable components. But I think it's actually failed at that. Most classes, objects, components, microservices end up failing in two respects: they end up reflecting the company's org chart more than anything else, and .. worse .. the bulk of the code and complexity ends up being how one moves data between all these (programmer created) systems rather than what the actual data is. The relationships (lines) between the boxes becomes the focus instead of the stuff was shoved into the box, and the whole behavior of the system becomes difficult to reason about. And when developers encounter systems that don't work along this model -- relational databases, functional programming, logic programming -- they often scratch their heads, resist, or wrap them up/confine them in OO/component type structures... damaging their usefulness.

by hurril 3y ago

kragen 3y ago

i am going to object to this; i've programmed in, among other things, prolog, ocaml, basic-80, c, the unadorned λ-calculus, bicicleta, and qfitzah, the last two of which are languages i designed and implemented myself and which have no mutability. moreover i don't think anyone would claim that basic-80 or c is object-oriented so i feel secure in claiming that i am more a walrus than a fish and therefore qualified to opine about water i do agree that identity and hidden mutability are important aspects of the oo view of the world, and that the author of these slides is off-base about what oo is. but i think that the essence of oo is that computation is done by sending messages to objects, but sending the same message to different objects invokes different code. this feature is present without mutability in bicicleta, and in abadi and cardelli's untyped ς-calculus, which it's based on; the ς-calculus was invented to formalize the essence of object-oriented typing the original intuition behind oo was to decompose a computer system into smaller computer systems, like a computer network; each object in the system was in effect a tiny computer, with its own private code and state. this was inspired by alan kay's undergraduate degree in biology, which mostly studies organisms made out of cells, which are basically tiny organisms. and in that formulation, obviously hidden mutability is the default, because you can't prevent a computer from changing its internal state as a result of a packet you send it; and mutability generally means identity is important but even more central to this formulation is the idea that different objects can behave differently in the same circumstances obviously none of this has anything to do with memory layout! except very indirectly

bruce343434 3y ago
This is it. OOP is about building sub programs with their own state and behaviours, yet implementing a common interface so they can still effectively communicate to each other. If you boil it down to the essence, this means branching logic is encoded via a function pointer. Instead of manually switching to the correct behavior using other branching mechanisms like if or switch. This is what polymorphism is about. It's pattern matching. An interface is like an Enum to which you can add entries after it has been defined, and the behaviour for that specific variant naturally then has to be encoded inside the variant itself.
- Gehinnn 3y ago
  Would it be far fetched to say object oriented programming is inspired by nature/physics? And thus, "more natural" than, let's say, procedural programming. Animals can be modeled nicely with objects/classes. Physical objects do have internal private state and public interfaces. Also in nature, usually, you have multiple similar objects that work the same but have different internal state.
  - bruce343434 3y ago
    That might have been what Alan Kay was going for with his "cells of an organism" thing, yes. But even if you're not inspired by biology, it might just come up "naturally". Separating your data into structs, then operations on those structs, and not wanting to deal with all kinds of bookkeeping all the time, letting things manage their own - separation of concerns, aka single responsibility principle. I think automatic memory management might be a big example of this. Who wants to bother with this malloc/free stuff all the time? Who wants to keep track of ownership everywhere? Instead, have a dedicated subsystem handle it. That allows a higher signal to noise ratio in all the rest of the code that would otherwise be polluted with malloc/free. It also removes the entire class of bugs that can happen when you inevitably forget either of those. But having memory management in and of itself isn't "OOP". It's just an example of one of the principles that people tout when they talk of "OOP". Those principles can and do apply broadly. Was Alan Kay thinking of all this? I really don't know. All I know is that the dude digs biology.

cmrdporcupine 3y ago

You've hit the nail on the head, and I think the replies below aren't getting your original point. Which I think is actually your point :-) The defining feature of OO approaches is in shifting the emphasis in sw development into the concept of identity-bags. All the other stuff about message passing, encapsulation, inheritance etc is just window dressing and implementation details of this core concept of identity-classification in software systems. I like how the "Out Of the Tarpit" (2006) paper breaks this down into the notion of "intentional" vs "extensional" identity, and I think this is a great model. For them, OO is all about "intentional identity" in that we create identities (objects, components) in our systems and move attributes and behavior onto them. OO shifts the analysis of software to identifying objects, components, services, and then makes software development all about the taxonomical management of them. In this model of software development, it's all about identifying components and then shuffling the data and functionality "into" them and managing the flow between them. (FWIW the paper identifies this way of thinking as one of the prime culprits in unnecessary complexity in software systems, and I agree with them.) The contrast is "extensional" identity, where identity in the software systems are emergent from their attributes. In this box we can put the relational data model, and its cousins in logic programming (prolog, datalog etc). In those systems, we are not concerned with "creating" identities and classifying systems/components/objects, but instead declaring the raw attributes -- tuples, facts, relations -- only. Queries then produce, at runtime, a multitude of results from permutations of those attributes. And, as you point out, equality/inequality is defined by the value of a tuples attributes, not by the object it lies in. This is crucial. There's a couple generations of software developers that are so immersed in the OO/intentional-identity way of thinking that they don't see that it's not intrinsic to software development, but actually a mental framework that was fostered through the 80s and 90s. It was an attempt to manage complexity and structure in software systems and also to create a marketplace of re-usable components. But I think it's actually failed at that. Most classes, objects, components, microservices end up failing in two respects: they end up reflecting the company's org chart more than anything else, and .. worse .. the bulk of the code and complexity ends up being how one moves data between all these (programmer created) systems rather than what the actual data is. The relationships (lines) between the boxes becomes the focus instead of the stuff was shoved into the box, and the whole behavior of the system becomes difficult to reason about. And when developers encounter systems that don't work along this model -- relational databases, functional programming, logic programming -- they often scratch their heads, resist, or wrap them up/confine them in OO/component type structures... damaging their usefulness.