5 ms·

I think you're falling into a thinking trap. And I think there's probably a name for it but I don't remember it. The point I will make is that "a car is an obj

I think you're falling into a thinking trap. And I think there's probably a name for it but I don't remember it. The point I will make is that "a car is an object you can do things with" is actually probably not how you think about a car. Personally I think of my car and the "objects" around me as merely tools I can use to achieve goals. If I need to go to the shop I don't think to myself: I need to go to the car object and call the door_open(DRIVER_SIDE) method and then call the add_driver(self) method and then the door_close(DRIVER_SIDE) method and then the turn_key() method... When I need to go to the shop I come up with a shopping list (or more likely get my girlfriend to send it to me) and then I think about my destination and how I can get there. I think of using my car to go there. So simply put, I think the object model has no relation to how we actually think about objects around us. The object model (At least alan kay's variant) may be a good description of how humans talk to each other, and I think it has its place for sure, but it's also nothing like the object model which gets sold to people these days. To me "network credentials permissions" sounds like just some data which describes the permissions required to access another piece of data called a network credential. That's how I think about it, I am not sure it's accurate to say that my method of thinking about it is any more or less natural than thinking of "network credentials permissions" as a thing but personally I would say that considering "network credentials permissions" to be a thing seems just outright wrong.

joe_the_user 6y ago
The point I will make is that "a car is an object you can do things with" is actually probably not how you think about a car. I can't imagine how this isn't exactly me or someone else thinks about a car. I might then think about what I accomplish with a car. And sure, "car" and "bicycle" are "transportation means I can steer" and feed "transport means" and "destination" into an algorithm and arrive a location. Sure, "transport means" is a higher logical level "car" but both of these go into human thought processes. If I need to go to the shop I don't think to myself: I need to go to the car object and call the door_open(DRIVER_SIDE) method and then call the add_driver(self) method and then the door_close(DRIVER_SIDE) method and then the turn_key() method... The only reason you don't think you think about that, is because your self-conception apparently delegates the process to your reflexes. But if you have explain to someone how this happens, you reflexively dive and give some English equivalent to your narative above.
- Arch-TK 6y ago
  > I can't imagine how this isn't exactly me or someone else thinks about a car. I think it's more likely that you think this is how you think about the car because you think it makes sense to think about a car that way. In reality if I recall correctly when we have a goal of "going somewhere" we don't see "objects" we see "obstacles and tools which overcome obstacles". Specifically you don't see what a car is (a lump of metal which moves with you inside) but rather you see what a car means (a tool which can be used to overcome the obstacle of distance). Although honestly I can't come up with what to look for on the net to source this information and I currently don't have time to do it. > The only reason you don't think you think about that, is because your self-conception apparently delegates the process to your reflexes. But if you have explain to someone how this happens, you reflexively dive and give some English equivalent to your narative above. Even if that is the case, I don't see how an English explanation can map onto an object model. It more closely approximates a procedural model. To point directly at the problem: Does the car contain me or am I riding the car? How do you describe this concept using objects? When you think of the car as a tool rather than a thing it becomes obvious: The car is a function which transforms some data <me> by changing the position from one place to another. With this approach I am no longer stuck trying to work out if I the car object has to have a add_driver() method or if I should have an ride_car() method.
  - meheleventyone 6y ago
    > To point directly at the problem: Does the car contain me or am I riding the car? How do you describe this concept using objects? When you think of the car as a tool rather than a thing it becomes obvious: The car is a function which transforms some data <me> by changing the position from one place to another. With this approach I am no longer stuck trying to work out if I the car object has to have a add_driver() method or if I should have an ride_car() method. Both and as someone who has implemented vehicle logic in a game before you usually want to model both. You’ve done the classic programmer thing of creating an abstraction over the grisly details with ride_car which is great if you’re just representing the fact abstractly but if not someone still needs to care about the details and model them. An abstract version is great then for example if you're planning but it doesn't remove the need to build the details out.
d23 6y ago
Damn, you really nailed it with that car example, because I can already see the sort of errors that might arise: * did not call putFeetInCar before adding driver * did not call putShoesOnFeet before calling putFeetInCar * did not call gripKeyInHand or set up HandKeyAllocator * did not set up HandKeyAllocatorManager or use KeyDashboardMeldConnector to insert key into KeyHoleDoodadInterfaceXConnector * did not do correct incantation of prayer to Cthulu to ensure AxelAlignmentProtocol is properly specified
- brundolf 6y ago
  Man, this really is the crux of it for me: when the focal point is a series of opaque state mutations, there are exponentially more ways to do those steps in the wrong order than the right order. And the contracts for those methods have absolutely zilch to say about what they assume has already happened or will happen after they're called. You just have to know (or hope somebody wrote it down in English). This is my biggest pain point/source of anxiety when working in an OOP codebase. And then guess what? Suddenly you're extremely concerned with the internal state of those objects. Because understanding it is essential if you want to have any hope of actually using them. And the great irony is that this completely undermines one of the main benefits of OOP: private state that the outside world doesn't have to care about.
- Toutouxc 6y ago
  > did not call putFeetInCar before adding driver > did not call putShoesOnFeet before calling putFeetInCar That's bad architecture, not an OOP flaw. These should've been private methods called and error-handled properly from driver.prepareForDriving, or even implemented as a DriverPreparedForDriving subtype. > did not set up HandKeyAllocatorManager or use KeyDashboardMeldConnector to insert key into KeyHoleDoodadInterfaceXConnector All these sound like bad OOP (or Java) to me, a HandKeyAllocatorManager is not a thing in the domain. I'd rather build my logic around objects like HandsContents, KeyKeyholeCompatibility or SeatedDriver.
  - d23 6y ago
    I’ve decided to assume this is perfect satire and have upvoted it accordingly.
gls2ro 6y ago
I think that the way we think about this has more to do with the purpose or intent and maybe with the language that we speak and it becomes more complex when thinking from self perspective. For me, for example describing a process where one person gives the car to another person to go somewhere it feel very easy to say person1.press car_key.button car.open_door person1.explains person2 person1.gives car_key to: person2 person2.enters car engine.starts car.moves Of course OO is not satisfying completely this but in general I see that nothing happens without someone/object/matter doing something on something else. So I except that something happens into/to the world because an object.did something to a subject. Else nothing happens. thus it does not feel natural to think first about an action that requires a force and the subject to be aplied to. Always an object is exercising an energy/force onto something else. To summarize I think if one is a person who thinks more about energy than matter then fp feels natural. If one is a person who things more about matter then oo is more natural.
hntrader 6y ago
We do go to the door and call door_open(DRIVER_SIDE) - it's just second nature now because we've done it so many times that it takes up no conscious bandwidth. But that subroutine is running somewhere in the brain. To use a car, we're performing a bunch of actions involving modifying the state of a car. That seems to be quite analogous to the OOP way of thinking. You're right that we don't consciously think of car travel in this way, but I don't see that as inconsistent with OOP either. Our thinking about cars is highly abstract, as though it's an abstract class/interface with a single go_somewhere(destination) method, which fits quite well with OOP thinking.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- bcrosby95 6y ago
  > Our thinking about cars is highly abstract, as though it's an abstract class/interface with a single go_somewhere(destination) method, which fits quite well with OOP thinking. So what you're saying is I'm going to have to downcast to a concrete class to figure out if my object is actually suitable for going to the store or my bathroom (my house isn't big enough to drive a car through). Lines up with most OOP systems I've worked in.
  - hntrader 6y ago
    Ideally the interface is named in a way that's self-documenting and makes it clear that it's not referring to moving around your house, no downcasting required.
- hnedeotes 6y ago
  But the thing is that now the car has to know about the world. If there's a wall on the driver side how can it open the door? I'm not dogmatic on OOP vs FP, but let me take the side of FP here, we could model this as the car being a data structure with its position (x, y, etc), and a representation of what opening the door is (width of the car + length of the door, an anonymous function, or a named function, that can be made polymorphic) and now our open_door(car, world) can take both and the world doesn't need to know about what is a car and the car doesn't need to know about the world either, it just serves as a mapping, and the function open_door checks the positions of car in the world, transforms the car according to its procedure and checks it still fits the world and if not it produces an annoying beep.

joe_the_user 6y ago

The point I will make is that "a car is an object you can do things with" is actually probably not how you think about a car. I can't imagine how this isn't exactly me or someone else thinks about a car. I might then think about what I accomplish with a car. And sure, "car" and "bicycle" are "transportation means I can steer" and feed "transport means" and "destination" into an algorithm and arrive a location. Sure, "transport means" is a higher logical level "car" but both of these go into human thought processes. If I need to go to the shop I don't think to myself: I need to go to the car object and call the door_open(DRIVER_SIDE) method and then call the add_driver(self) method and then the door_close(DRIVER_SIDE) method and then the turn_key() method... The only reason you don't think you think about that, is because your self-conception apparently delegates the process to your reflexes. But if you have explain to someone how this happens, you reflexively dive and give some English equivalent to your narative above.

Arch-TK 6y ago
> I can't imagine how this isn't exactly me or someone else thinks about a car. I think it's more likely that you think this is how you think about the car because you think it makes sense to think about a car that way. In reality if I recall correctly when we have a goal of "going somewhere" we don't see "objects" we see "obstacles and tools which overcome obstacles". Specifically you don't see what a car is (a lump of metal which moves with you inside) but rather you see what a car means (a tool which can be used to overcome the obstacle of distance). Although honestly I can't come up with what to look for on the net to source this information and I currently don't have time to do it. > The only reason you don't think you think about that, is because your self-conception apparently delegates the process to your reflexes. But if you have explain to someone how this happens, you reflexively dive and give some English equivalent to your narative above. Even if that is the case, I don't see how an English explanation can map onto an object model. It more closely approximates a procedural model. To point directly at the problem: Does the car contain me or am I riding the car? How do you describe this concept using objects? When you think of the car as a tool rather than a thing it becomes obvious: The car is a function which transforms some data <me> by changing the position from one place to another. With this approach I am no longer stuck trying to work out if I the car object has to have a add_driver() method or if I should have an ride_car() method.
- meheleventyone 6y ago
  > To point directly at the problem: Does the car contain me or am I riding the car? How do you describe this concept using objects? When you think of the car as a tool rather than a thing it becomes obvious: The car is a function which transforms some data <me> by changing the position from one place to another. With this approach I am no longer stuck trying to work out if I the car object has to have a add_driver() method or if I should have an ride_car() method. Both and as someone who has implemented vehicle logic in a game before you usually want to model both. You’ve done the classic programmer thing of creating an abstraction over the grisly details with ride_car which is great if you’re just representing the fact abstractly but if not someone still needs to care about the details and model them. An abstract version is great then for example if you're planning but it doesn't remove the need to build the details out.

d23 6y ago

Damn, you really nailed it with that car example, because I can already see the sort of errors that might arise: * did not call putFeetInCar before adding driver * did not call putShoesOnFeet before calling putFeetInCar * did not call gripKeyInHand or set up HandKeyAllocator * did not set up HandKeyAllocatorManager or use KeyDashboardMeldConnector to insert key into KeyHoleDoodadInterfaceXConnector * did not do correct incantation of prayer to Cthulu to ensure AxelAlignmentProtocol is properly specified

brundolf 6y ago
Man, this really is the crux of it for me: when the focal point is a series of opaque state mutations, there are exponentially more ways to do those steps in the wrong order than the right order. And the contracts for those methods have absolutely zilch to say about what they assume has already happened or will happen after they're called. You just have to know (or hope somebody wrote it down in English). This is my biggest pain point/source of anxiety when working in an OOP codebase. And then guess what? Suddenly you're extremely concerned with the internal state of those objects. Because understanding it is essential if you want to have any hope of actually using them. And the great irony is that this completely undermines one of the main benefits of OOP: private state that the outside world doesn't have to care about.
Toutouxc 6y ago
> did not call putFeetInCar before adding driver > did not call putShoesOnFeet before calling putFeetInCar That's bad architecture, not an OOP flaw. These should've been private methods called and error-handled properly from driver.prepareForDriving, or even implemented as a DriverPreparedForDriving subtype. > did not set up HandKeyAllocatorManager or use KeyDashboardMeldConnector to insert key into KeyHoleDoodadInterfaceXConnector All these sound like bad OOP (or Java) to me, a HandKeyAllocatorManager is not a thing in the domain. I'd rather build my logic around objects like HandsContents, KeyKeyholeCompatibility or SeatedDriver.
- d23 6y ago
  I’ve decided to assume this is perfect satire and have upvoted it accordingly.

gls2ro 6y ago

I think that the way we think about this has more to do with the purpose or intent and maybe with the language that we speak and it becomes more complex when thinking from self perspective. For me, for example describing a process where one person gives the car to another person to go somewhere it feel very easy to say person1.press car_key.button car.open_door person1.explains person2 person1.gives car_key to: person2 person2.enters car engine.starts car.moves Of course OO is not satisfying completely this but in general I see that nothing happens without someone/object/matter doing something on something else. So I except that something happens into/to the world because an object.did something to a subject. Else nothing happens. thus it does not feel natural to think first about an action that requires a force and the subject to be aplied to. Always an object is exercising an energy/force onto something else. To summarize I think if one is a person who thinks more about energy than matter then fp feels natural. If one is a person who things more about matter then oo is more natural.

hntrader 6y ago

We do go to the door and call door_open(DRIVER_SIDE) - it's just second nature now because we've done it so many times that it takes up no conscious bandwidth. But that subroutine is running somewhere in the brain. To use a car, we're performing a bunch of actions involving modifying the state of a car. That seems to be quite analogous to the OOP way of thinking. You're right that we don't consciously think of car travel in this way, but I don't see that as inconsistent with OOP either. Our thinking about cars is highly abstract, as though it's an abstract class/interface with a single go_somewhere(destination) method, which fits quite well with OOP thinking.

deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
bcrosby95 6y ago
> Our thinking about cars is highly abstract, as though it's an abstract class/interface with a single go_somewhere(destination) method, which fits quite well with OOP thinking. So what you're saying is I'm going to have to downcast to a concrete class to figure out if my object is actually suitable for going to the store or my bathroom (my house isn't big enough to drive a car through). Lines up with most OOP systems I've worked in.
- hntrader 6y ago
  Ideally the interface is named in a way that's self-documenting and makes it clear that it's not referring to moving around your house, no downcasting required.
hnedeotes 6y ago
But the thing is that now the car has to know about the world. If there's a wall on the driver side how can it open the door? I'm not dogmatic on OOP vs FP, but let me take the side of FP here, we could model this as the car being a data structure with its position (x, y, etc), and a representation of what opening the door is (width of the car + length of the door, an anonymous function, or a named function, that can be made polymorphic) and now our open_door(car, world) can take both and the world doesn't need to know about what is a car and the car doesn't need to know about the world either, it just serves as a mapping, and the function open_door checks the positions of car in the world, transforms the car according to its procedure and checks it still fits the world and if not it produces an annoying beep.