4 ms·

Object oriented programming is good. Not in absolutely every situation, but for most business applications it's better than the alternatives. The thing about O

Object oriented programming is good. Not in absolutely every situation, but for most business applications it's better than the alternatives. The thing about OO is that as far as I can tell, it's natural. Whatever OO is criticized, people point out that the standard OO example is "car" but the typical OO object in practice is "network credentials permissions". So what? The usefulness of OO is exactly that allows, partially, some totally fungly thing like "network credentials permissions" to be treated, sort of, like a thing, we sort of, understand, a fricken car. And further thing is, the fp thing seems to be something like "we don't do objects at all but we do really elaborate Turing complete types, please don't ask us what the difference is, you wouldn't understand. Don't ask us whether types have private data. Especially don't ask if integers have private bits..."

Arch-TK 6y ago
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.
mmis1000 6y ago
The problem mostly caused by people insists use OO in position where is looks not natural nor make sense. A connection client is suitable to be written as a class. It didn't make sense for outsider to see what the internal connection state is and manipulate it randomly. You want to just call .connect() and happily use methods on it. But makes a math method be a class with multi constructor parameter just don't make sense, why not just make it a static method or a bare function(If the language supports it) with multi parameter? And the most worst problem(Though it is not related to this topic). Someone writes pattern from OO language in other language. Even the language itself has the capability to express it directly and gracefully. (personally I think this is why OO haters exists...)
- watwut 6y ago
  > The problem mostly caused by people insists use OO in position where is looks not natural nor make sense. You have exactly the same issue with any paradigm. I am seeing it now with functional programming as people go all obsessive into converting everything into it.
  - yellowapple 6y ago
    And I'd argue than in both cases trying to use a paradigm for literally everything is a good thing, at least in terms of learning and understanding that paradigm. Is OO good for everything? No. Is FP good for everything? No. And yet, unless you've attempted to use them for everything, you're unlikely to understand why they ain't good for everything.
- joe_the_user 6y ago
  The problem mostly caused by people insists use OO in position where is looks not natural nor make sense. Another poster mentioned that any paradigm can be misused. Yes but OO has a sort-of "least bad to miss-use" quality. You can have a date object or a query object or Haskell-function object, and they are all conceptually terrible but they still allow people who only know OO to work with all kinds of things. OO is created to "glue" anything together with anything else. The equivalent with functional programming is "FP is created to "glue" only other functional elements together with other functional elements". And OO definitely offends the sensibility of those who things done correctly and well - which includes lots of programmers. The "least bad" is indeed an enemy of the good. But you're not going to get all the world's systems redone correctly as the new paradigm so if you want to end OO, you'd need an alternative that could also least bad in many circumstances.
deleted 6y ago
[deleted]
coldtea 6y ago
>The thing about OO is that as far as I can tell, it's natural How so? If it was natural, it wouldn't take 30 years of programming to arrive to it (and in a bad way). >The usefulness of OO is exactly that allows, partially, some totally fungly thing like "network credentials permissions" to be treated, sort of, like a thing, we sort of, understand, a fricken car. Cars have instance variables and methods? You car.drive() your car?
- jgrimm 6y ago
  I mean at the right level of abstraction - yes...?
dkersten 6y ago
You can represent "network credentials permissions" or "car" naturally in non-OO too though. Non-OO-procedural programmers would probably create a struct representing the credentials and have a bunch of (hopefully namespaced) freestanding functions to operate on it, just like OO has a bunch of methods operating on the class. Functional programmers would similarly represent that as a data structure and a set of functions to operate on it. Furthermore, since the data structures used are usually the core language provided ones, you can use the full collection of the languages library of functions to operate on it to transform, filter or otherwise process the data. You can do that with OO too, of course, except that encapsulation means you typically do it in the class and if you want to do other transformations, you either need to amend the class, expose the internal data (directly or through getters/setters), or inherit from the class. In a functional or procedural language you can also provide encapsulation/data hiding if you wish. I don't think either approach is more natural than the other and they're both more or less equivalent, its just that different languages encourage different default approaches. Personally, after twenty years of programming, I find that I value immutable data over all in most cases (ie unless I'm writing performance-sensitive C++ code) and as long as I have that and a reasonable way of managing it, I don't really mind if I'm representing things as immutable objects or something else.

Arch-TK 6y ago

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.

mmis1000 6y ago

The problem mostly caused by people insists use OO in position where is looks not natural nor make sense. A connection client is suitable to be written as a class. It didn't make sense for outsider to see what the internal connection state is and manipulate it randomly. You want to just call .connect() and happily use methods on it. But makes a math method be a class with multi constructor parameter just don't make sense, why not just make it a static method or a bare function(If the language supports it) with multi parameter? And the most worst problem(Though it is not related to this topic). Someone writes pattern from OO language in other language. Even the language itself has the capability to express it directly and gracefully. (personally I think this is why OO haters exists...)

watwut 6y ago
> The problem mostly caused by people insists use OO in position where is looks not natural nor make sense. You have exactly the same issue with any paradigm. I am seeing it now with functional programming as people go all obsessive into converting everything into it.
- yellowapple 6y ago
  And I'd argue than in both cases trying to use a paradigm for literally everything is a good thing, at least in terms of learning and understanding that paradigm. Is OO good for everything? No. Is FP good for everything? No. And yet, unless you've attempted to use them for everything, you're unlikely to understand why they ain't good for everything.
joe_the_user 6y ago
The problem mostly caused by people insists use OO in position where is looks not natural nor make sense. Another poster mentioned that any paradigm can be misused. Yes but OO has a sort-of "least bad to miss-use" quality. You can have a date object or a query object or Haskell-function object, and they are all conceptually terrible but they still allow people who only know OO to work with all kinds of things. OO is created to "glue" anything together with anything else. The equivalent with functional programming is "FP is created to "glue" only other functional elements together with other functional elements". And OO definitely offends the sensibility of those who things done correctly and well - which includes lots of programmers. The "least bad" is indeed an enemy of the good. But you're not going to get all the world's systems redone correctly as the new paradigm so if you want to end OO, you'd need an alternative that could also least bad in many circumstances.

deleted 6y ago

[deleted]

coldtea 6y ago

>The thing about OO is that as far as I can tell, it's natural How so? If it was natural, it wouldn't take 30 years of programming to arrive to it (and in a bad way). >The usefulness of OO is exactly that allows, partially, some totally fungly thing like "network credentials permissions" to be treated, sort of, like a thing, we sort of, understand, a fricken car. Cars have instance variables and methods? You car.drive() your car?

jgrimm 6y ago
I mean at the right level of abstraction - yes...?

dkersten 6y ago

You can represent "network credentials permissions" or "car" naturally in non-OO too though. Non-OO-procedural programmers would probably create a struct representing the credentials and have a bunch of (hopefully namespaced) freestanding functions to operate on it, just like OO has a bunch of methods operating on the class. Functional programmers would similarly represent that as a data structure and a set of functions to operate on it. Furthermore, since the data structures used are usually the core language provided ones, you can use the full collection of the languages library of functions to operate on it to transform, filter or otherwise process the data. You can do that with OO too, of course, except that encapsulation means you typically do it in the class and if you want to do other transformations, you either need to amend the class, expose the internal data (directly or through getters/setters), or inherit from the class. In a functional or procedural language you can also provide encapsulation/data hiding if you wish. I don't think either approach is more natural than the other and they're both more or less equivalent, its just that different languages encourage different default approaches. Personally, after twenty years of programming, I find that I value immutable data over all in most cases (ie unless I'm writing performance-sensitive C++ code) and as long as I have that and a reasonable way of managing it, I don't really mind if I'm representing things as immutable objects or something else.