3 ms·

Huh. I don't see any conflict between loving OO-programming and also loving types. Isn't 9/10ths of OO just about consolidating your business logic into interfa

Huh. I don't see any conflict between loving OO-programming and also loving types. Isn't 9/10ths of OO just about consolidating your business logic into interfaces and types that you'd ideally want to re-use? I feel like if it's not, then people are using OO the wrong way.

9rx 2y ago
You can love conflicting things, but the basis of OO programming, that which makes it object-oriented and not just object-based, is message passing, which sees messages flow between objects for inspection. That is inherently runtime behaviour which is at odds with static type enforcement.
- pjmlp 2y ago
  As shown by The Art of Metaobject Protocol that is the genesis of CLOS, not really.
  - 9rx 2y ago
    The Art of the Metaobject Protocol does not seem to go into any detail about senders sending blobs of data to receivers. What do you think it shows, exactly? That you don't need to send blobs of data? That should be obvious by the fact that you can count the number of languages that support that concept on one hand, but does not remove that message passing when employed is necessarily dependent on runtime.
    - pjmlp 2y ago
      It shows that message passing and types get along just fine.
      - 9rx 2y ago
        It is not like they are sworn enemies, but as messages can originate from outside the program, they cannot be typed statically. It is impossible to know what types will appear before runtime. For messages that originate from within the same codebase, you can, perhaps, start to layer static typing on top, but it can only be a partial solution as it remains that messages can come from other sources.
        pjmlp 2y ago
        Then we are talking about distributed computing, and nothing will help you understand that glob of undefined bytes. This has nothing to do with OOP.
        9rx 2y ago
        > Then we are talking about distributed computing You must have a funny definition of distributed computing, then. OO never really caught on, probably because accepting "globs of undefined bytes" is kind of sucky, but we see some examples in the wild. Interface Builder is probably the best example of where we really leaned into OO, orienting a program's UI objects from externally defined messages. I'm not sure what building user interfaces has to do with distributed computing, but... I guess?
        pjmlp 2y ago
        "Messages that originate outside of the program" is distributed computing, regardless of it is on the same computing node, or across the network. Multiple processes are involved, giving meaning to a byte stream. I am quite sure Interface Builder has enough Objective-C type definitions, as does Portable Distributed Objects. Additionally, those mapping definitions on the UI are nothing else than a type system powering the whole experience.
        9rx 2y ago
        > Multiple processes are involved, giving meaning to a byte stream. Maybe in the case of Erlang, but that's a fairly unique case. Smalltalk[1], and by extension Objective-C, do not pass messages across processes. Languages don't normally concern themselves with that kind of thing at all. You can build distributed computing on top of languages (pretty much any language), but that's not a trait of the language and way beyond the topic at hand. [1] Which is what matters most as OO was literally defined by the design of Smalltalk.
        igouy 2y ago
- noduerme 2y ago
  The whole point of static typing is to ensure that runtime behavior is consistent with what gets passed. Right? The beauty of a typed OO language (like AS3 or TS) is that you immediately know if you might be referencing something using the wrong type. The only major language where every variable is cast/guessed in message passing at runtime is in naked Javascript, where everything's type is any/wildcard. It's such a shitty ridiculous language that they had to build an entire type system for serious coders to compile down to it. But in pure form, a well typed OO language should never run into undefined behavior at runtime. Runtime interpolation is not an inherent drawback, or a logical outcome of OO languages. Some of them were just designed to be incredibly loose.
  - 9rx 2y ago
    > The whole point of static typing is to ensure that runtime behavior is consistent with what gets passed. Right? More or less. While the whole point of object-oriented programming is that behaviour is defined at runtime through the passage of messages. The messages may originate from the very same codebase, but not necessarily. Consider something like NeXT's Interface Builder, which relied heavily on injecting messages into the program externally. > But in pure form, a well typed OO language should never run into undefined behaviour at runtime. It is not known until runtime what kind of messages will appear. You can define what should happen when an "unknown" message shows up (ignore it, for example), but you cannot statically prove that it won't occur. –– If you could, what do you need OO for?
    - noduerme 2y ago
      For the way you think about and reference data (if you can ensure type safety). To me, the advantage of OO is to give data objects methods so you can extract or modify what you want, how you want. The confusion that seems to arise is when coders think that objects and classes should "do things" or "make things". Anything that can be static, should be static. And anything that can be instantiated directly, should be instantiated directly. Factories and singletons should always be viewed as compromises against the nature of OO languages, and their presence minimized. Take a particle system. Let's say each particle is an instance of a class with velocity and position. An attractor/repeller is also an object with V/P and some other features. These could all just be a [x,y,vx,vy,u,v,w] array that some global functions operate on, but then you'd lose inheritance as well as readability. The thing that runs that particle system on a loop, which manages all those tiny objects? It doesn't need to be its own object. Tie the delta function to the main timer for your game. And the main timer for your game? It shouldn't have multiple instances, right? It's about as central to Main() as anything else. There are lots of things in code that there should only be one of. Trying to shoehorn those things into objects and classes is where OO goes wrong and you end up with multiple timers or things that aren't expunged from memory. However: Is it nice to manage an array of Particle objects with .x .y .vx and .vy, and some nifty methods to get and set those? Instead of writing that code to crunch through the same data on a flat 1-D array of all particles? Yeah. That's the point of OO.
- DaiPlusPlus 2y ago
  Swift has built-in support for actor-classes - which are strongly-typed too (not that it wasn't already easy-enough to define a self-driven actor class without the added syntactic-sugar) - I'm curious if you've tried that and how it fits into your notions of what OOP should be like.
  - 9rx 2y ago
    I haven't used Swift since that addition, but last time I used it Swift had removed messages passing (unless you revert back to @objc mode). A look at actors does not suggest that message passing is back. What did I miss?

9rx 2y ago

You can love conflicting things, but the basis of OO programming, that which makes it object-oriented and not just object-based, is message passing, which sees messages flow between objects for inspection. That is inherently runtime behaviour which is at odds with static type enforcement.

pjmlp 2y ago
As shown by The Art of Metaobject Protocol that is the genesis of CLOS, not really.
- 9rx 2y ago
  The Art of the Metaobject Protocol does not seem to go into any detail about senders sending blobs of data to receivers. What do you think it shows, exactly? That you don't need to send blobs of data? That should be obvious by the fact that you can count the number of languages that support that concept on one hand, but does not remove that message passing when employed is necessarily dependent on runtime.
  - pjmlp 2y ago
    It shows that message passing and types get along just fine.
    - 9rx 2y ago
      It is not like they are sworn enemies, but as messages can originate from outside the program, they cannot be typed statically. It is impossible to know what types will appear before runtime. For messages that originate from within the same codebase, you can, perhaps, start to layer static typing on top, but it can only be a partial solution as it remains that messages can come from other sources.
      - pjmlp 2y ago
        Then we are talking about distributed computing, and nothing will help you understand that glob of undefined bytes. This has nothing to do with OOP.
        9rx 2y ago
        > Then we are talking about distributed computing You must have a funny definition of distributed computing, then. OO never really caught on, probably because accepting "globs of undefined bytes" is kind of sucky, but we see some examples in the wild. Interface Builder is probably the best example of where we really leaned into OO, orienting a program's UI objects from externally defined messages. I'm not sure what building user interfaces has to do with distributed computing, but... I guess?
        pjmlp 2y ago
        "Messages that originate outside of the program" is distributed computing, regardless of it is on the same computing node, or across the network. Multiple processes are involved, giving meaning to a byte stream. I am quite sure Interface Builder has enough Objective-C type definitions, as does Portable Distributed Objects. Additionally, those mapping definitions on the UI are nothing else than a type system powering the whole experience.
        9rx 2y ago
        > Multiple processes are involved, giving meaning to a byte stream. Maybe in the case of Erlang, but that's a fairly unique case. Smalltalk[1], and by extension Objective-C, do not pass messages across processes. Languages don't normally concern themselves with that kind of thing at all. You can build distributed computing on top of languages (pretty much any language), but that's not a trait of the language and way beyond the topic at hand. [1] Which is what matters most as OO was literally defined by the design of Smalltalk.
        igouy 2y ago
noduerme 2y ago
The whole point of static typing is to ensure that runtime behavior is consistent with what gets passed. Right? The beauty of a typed OO language (like AS3 or TS) is that you immediately know if you might be referencing something using the wrong type. The only major language where every variable is cast/guessed in message passing at runtime is in naked Javascript, where everything's type is any/wildcard. It's such a shitty ridiculous language that they had to build an entire type system for serious coders to compile down to it. But in pure form, a well typed OO language should never run into undefined behavior at runtime. Runtime interpolation is not an inherent drawback, or a logical outcome of OO languages. Some of them were just designed to be incredibly loose.
- 9rx 2y ago
  > The whole point of static typing is to ensure that runtime behavior is consistent with what gets passed. Right? More or less. While the whole point of object-oriented programming is that behaviour is defined at runtime through the passage of messages. The messages may originate from the very same codebase, but not necessarily. Consider something like NeXT's Interface Builder, which relied heavily on injecting messages into the program externally. > But in pure form, a well typed OO language should never run into undefined behaviour at runtime. It is not known until runtime what kind of messages will appear. You can define what should happen when an "unknown" message shows up (ignore it, for example), but you cannot statically prove that it won't occur. –– If you could, what do you need OO for?
  - noduerme 2y ago
    For the way you think about and reference data (if you can ensure type safety). To me, the advantage of OO is to give data objects methods so you can extract or modify what you want, how you want. The confusion that seems to arise is when coders think that objects and classes should "do things" or "make things". Anything that can be static, should be static. And anything that can be instantiated directly, should be instantiated directly. Factories and singletons should always be viewed as compromises against the nature of OO languages, and their presence minimized. Take a particle system. Let's say each particle is an instance of a class with velocity and position. An attractor/repeller is also an object with V/P and some other features. These could all just be a [x,y,vx,vy,u,v,w] array that some global functions operate on, but then you'd lose inheritance as well as readability. The thing that runs that particle system on a loop, which manages all those tiny objects? It doesn't need to be its own object. Tie the delta function to the main timer for your game. And the main timer for your game? It shouldn't have multiple instances, right? It's about as central to Main() as anything else. There are lots of things in code that there should only be one of. Trying to shoehorn those things into objects and classes is where OO goes wrong and you end up with multiple timers or things that aren't expunged from memory. However: Is it nice to manage an array of Particle objects with .x .y .vx and .vy, and some nifty methods to get and set those? Instead of writing that code to crunch through the same data on a flat 1-D array of all particles? Yeah. That's the point of OO.
DaiPlusPlus 2y ago
Swift has built-in support for actor-classes - which are strongly-typed too (not that it wasn't already easy-enough to define a self-driven actor class without the added syntactic-sugar) - I'm curious if you've tried that and how it fits into your notions of what OOP should be like.
- 9rx 2y ago
  I haven't used Swift since that addition, but last time I used it Swift had removed messages passing (unless you revert back to @objc mode). A look at actors does not suggest that message passing is back. What did I miss?