4 ms·

OO is simply a layer of human-readability on top of functions and data. As far as the CPU is concerned, both object and method arguments are just data to operat

OO is simply a layer of human-readability on top of functions and data. As far as the CPU is concerned, both object and method arguments are just data to operate on. So `steve.drink(water)` in another context is just `drink(steve, water)`, which is a little more difficult (at least in English) to reason about. OO principles are for the limitations of people, not computers.

chongli 12y ago
I should hope it'd be obvious to most people that you don't actually need all of OO just to get that little bit of syntactic sugar. I'd also like to point out another obvious fact: this idiom completely breaks down when the subject happens to be more than one person, i.e: steve_and_irene.drink(water) whereas it works fine in the procedural case (thanks to varargs): drink(water,steve,irene,...).
- seanmcdirmid 12y ago
  And you don't need syntactic sugar to do OOP, as you have just demonstrated with your examples. And also, multi methods exist, but you probably want one subject/dispatch variation per sentence anyways for complexity reasons.
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- PJDK 12y ago
  Only if your model is terrible. It's perfectly possible to have thirsty_people.drink(water).
- snlacks 12y ago
  I think the more realistic code would be. people.find('thirsty').drink('water') Not about plain language reading, but instead writing code the way people think about actions and things. Procedural is just as valid, but you use the right tool for the right job.
deleted 12y ago
[deleted]
adunn 12y ago
This is correct. OO codifies the pattern of having a struct and a set of functions that operate on it. The syntax does help humans reason about that pattern. But my understanding is that the goal is more about the human limitations of managing large code bases than the human limitations of language. OO is all about encapsulation. We tend to decompose a program into chunks for different teams and individuals to work on. Software development is a distributed task. Encapsulation means when you code against components written by other people, you only have to understand the public API that they provided. You are supposed to be guaranteed that that API will continue to work even as the code behind it is updated. As component users we can focus on our own task and not worry so much about the details of the component. As the author of a component, we can hide state from the users. That can't be done with structs. we can make updates and switch out implementations without (as much) fear of breaking the code that depends on it. It's really all about being able to modify code more safely on bigger teams. In my mind the issues that OO introduces are: * Encapsulation results in more verbosity for the same functionality. * Inheritance takes more thought. * OO as a whole is more complicated and has a bigger learning curve. * OO used incorrectly will magnify the first two points greatly. Given the learning curve I imagine a lot of people don't use it fully correctly.
colanderman 12y ago
Which is great until you have to OO-ify `playWith(steve, bob, ball)`. OO dictates that one of steve, bob, or the ball, knows how these three interact, and that it not vary with respect to the other two. Or `steve' is given to you from a 3rd-party library, and you want to imbue him with the ability also to eat. Well, you can't define `steve.eat(salad)', unless you subclass his class and make a proxy of the object from the library. To properly solve either of these, you are forced to resort to the second-class citizen of a static class, which is exactly just functions in a namespace. The one actual "benefit" OO gives you is run-time dispatch; the ability for the program to defer until run-time the decision which implementation of `steve' actually handles `.drink()'. Outside of OO's poster child of GUIs, I have rarely seen a need for this capability in 20+ years of programming. (Mere compile-time dispatch, as captured precisely by OCaml's module functors, is much more common.) Centering a paradigm around this rarity is quite bizarre.

chongli 12y ago

I should hope it'd be obvious to most people that you don't actually need all of OO just to get that little bit of syntactic sugar. I'd also like to point out another obvious fact: this idiom completely breaks down when the subject happens to be more than one person, i.e: steve_and_irene.drink(water) whereas it works fine in the procedural case (thanks to varargs): drink(water,steve,irene,...).

seanmcdirmid 12y ago
And you don't need syntactic sugar to do OOP, as you have just demonstrated with your examples. And also, multi methods exist, but you probably want one subject/dispatch variation per sentence anyways for complexity reasons.
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
PJDK 12y ago
Only if your model is terrible. It's perfectly possible to have thirsty_people.drink(water).
snlacks 12y ago
I think the more realistic code would be. people.find('thirsty').drink('water') Not about plain language reading, but instead writing code the way people think about actions and things. Procedural is just as valid, but you use the right tool for the right job.

deleted 12y ago

[deleted]

adunn 12y ago

This is correct. OO codifies the pattern of having a struct and a set of functions that operate on it. The syntax does help humans reason about that pattern. But my understanding is that the goal is more about the human limitations of managing large code bases than the human limitations of language. OO is all about encapsulation. We tend to decompose a program into chunks for different teams and individuals to work on. Software development is a distributed task. Encapsulation means when you code against components written by other people, you only have to understand the public API that they provided. You are supposed to be guaranteed that that API will continue to work even as the code behind it is updated. As component users we can focus on our own task and not worry so much about the details of the component. As the author of a component, we can hide state from the users. That can't be done with structs. we can make updates and switch out implementations without (as much) fear of breaking the code that depends on it. It's really all about being able to modify code more safely on bigger teams. In my mind the issues that OO introduces are: * Encapsulation results in more verbosity for the same functionality. * Inheritance takes more thought. * OO as a whole is more complicated and has a bigger learning curve. * OO used incorrectly will magnify the first two points greatly. Given the learning curve I imagine a lot of people don't use it fully correctly.

colanderman 12y ago

Which is great until you have to OO-ify `playWith(steve, bob, ball)`. OO dictates that one of steve, bob, or the ball, knows how these three interact, and that it not vary with respect to the other two. Or `steve' is given to you from a 3rd-party library, and you want to imbue him with the ability also to eat. Well, you can't define `steve.eat(salad)', unless you subclass his class and make a proxy of the object from the library. To properly solve either of these, you are forced to resort to the second-class citizen of a static class, which is exactly just functions in a namespace. The one actual "benefit" OO gives you is run-time dispatch; the ability for the program to defer until run-time the decision which implementation of `steve' actually handles `.drink()'. Outside of OO's poster child of GUIs, I have rarely seen a need for this capability in 20+ years of programming. (Mere compile-time dispatch, as captured precisely by OCaml's module functors, is much more common.) Centering a paradigm around this rarity is quite bizarre.