3 ms·

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 T

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.
  - xigoi 2y ago
    > 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. You don’t need OO for that. Procedural languages have structures and procedures. Functional languages have records and functions.
  - 9rx 2y ago
    > To me, the advantage of OO is to give data objects methods so you can extract or modify what you want, how you want. Encapsulation is a trait of functional programming. You don't need OO to create 'objects' that offer 'methods' to extract or modify the encapsulated data. OO is all about message passing; that is what sets it apart from other programming concepts. If you don't allow messages from external sources (thus fundamentally requiring dynamic runtime behaviour), you can do boring old static binding which is going to be way faster.

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.
- xigoi 2y ago
  > 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. You don’t need OO for that. Procedural languages have structures and procedures. Functional languages have records and functions.
- 9rx 2y ago
  > To me, the advantage of OO is to give data objects methods so you can extract or modify what you want, how you want. Encapsulation is a trait of functional programming. You don't need OO to create 'objects' that offer 'methods' to extract or modify the encapsulated data. OO is all about message passing; that is what sets it apart from other programming concepts. If you don't allow messages from external sources (thus fundamentally requiring dynamic runtime behaviour), you can do boring old static binding which is going to be way faster.