I use Max, and I haven't fallen in love with OOP.
Some aspects of OOP are nice. For example, methods. At first, I didn't like putting methods in my types. I thought it would be messy. And the way most people format them, they are. I found a way to format them that I'm happy with though.
Methods are nice, because they save you a lot of typing when accessing the object's fields, and you can treat functions that return information about an object just like you would variables.
On the flip side, you can't actually treat functions just like variables. I can't assign a function a value, I have to pass it values. So it is not entirely hidden that Sprite.X# is not the same as Sprite.Y#().
In addition it is hard to design objects that make sense, if you want to keep certain things conceptually seperate.
For example, in my sprite system, I have a sprite type, an animation type, and a physics type. I have to have the animation type if only to store animation instances, but I could stick almost all the functions in it in the sprite type. And all the physics stuff could be stuck in the sprite type as well.
But conceptually, this doesn't make sense to me. If I have a calculator and I want to push it across the table, I don't say to myself Calculator.ApplyForce! Though I might think Hand.ApplyForceTo(Calculator). But what if nothing, at least, no other sprite, is actually applying a force to that calculator, but the force most certainly is coming from an external source, say a point? Unless I want to create a point object just to hold points and then give points the ability to apply forces to objects which conceptually is just silly, the object oriented paradigm breaks down. Cause if I go Calculator.Accelerate() then I'm implying that the calculator has a rocket strapped to it.
So, I don't agree that OOP is closer to the way people think. I think people make lists of things they need to do, and do them.
Some aspects of OOP are nice. For example, methods. At first, I didn't like putting methods in my types. I thought it would be messy. And the way most people format them, they are. I found a way to format them that I'm happy with though.
Methods are nice, because they save you a lot of typing when accessing the object's fields, and you can treat functions that return information about an object just like you would variables.
On the flip side, you can't actually treat functions just like variables. I can't assign a function a value, I have to pass it values. So it is not entirely hidden that Sprite.X# is not the same as Sprite.Y#().
In addition it is hard to design objects that make sense, if you want to keep certain things conceptually seperate.
For example, in my sprite system, I have a sprite type, an animation type, and a physics type. I have to have the animation type if only to store animation instances, but I could stick almost all the functions in it in the sprite type. And all the physics stuff could be stuck in the sprite type as well.
But conceptually, this doesn't make sense to me. If I have a calculator and I want to push it across the table, I don't say to myself Calculator.ApplyForce! Though I might think Hand.ApplyForceTo(Calculator). But what if nothing, at least, no other sprite, is actually applying a force to that calculator, but the force most certainly is coming from an external source, say a point? Unless I want to create a point object just to hold points and then give points the ability to apply forces to objects which conceptually is just silly, the object oriented paradigm breaks down. Cause if I go Calculator.Accelerate() then I'm implying that the calculator has a rocket strapped to it.
So, I don't agree that OOP is closer to the way people think. I think people make lists of things they need to do, and do them.