4 ms·

But what you describe are basically namespaces. All the rest of OO is overkill. Recipe for success: take a simple language with only functions (like Lisp or C)

But what you describe are basically namespaces. All the rest of OO is overkill. Recipe for success: take a simple language with only functions (like Lisp or C) and add namespaces. Result: this language can do 90 % of what OO languages are useful for, with only 10 % of the features.

hrjet 12y ago
IMO apart from namespaces, the other biggest convenience provided by OO is inheritance. In some problem domains, there are naturally emerging inheritance hierarchies. And when you need it, manually coding virtual dispatch in non-OO languages is going to be hairy.
andrewstuart2 12y ago
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.
oblio 12y ago
Isn't also limiting the potentially boundless array of (mostly irrelevant) functions to relevant data types also relevant? I'd venture to say it is. Ooooh... that's a Point object - no way the AddAccount function does anything relevant with it! In OO you don't even actually need to think that since Point has a limited set of methods.
- deleted 12y ago
  [deleted]
- sbov 12y ago
  I'd be willing to bet that the Point object in any given language is going to have more methods that take it as an argument than methods the class itself has.
  - oblio 12y ago
    True. But I still go looking for the "Point" class first. Then I start looking for things which accept "Point" parameters. Big difference from procedural programming languages.
    - colanderman 12y ago
      In C, I look in "point.h" first, then start looking for other things. Not really different.
  - hrjet 12y ago
    A natural way to separate those two types of methods is: * methods that do something *to* a Point object * methods that do something *with* a Point object The former are better to be declared inside the Point object so that they have access to internal state. The latter shouldn't typically access internal state of the Point object. This separation can help immensely while analyzing a code base.
- colanderman 12y ago
  This applies to any language with static types. Or that allows code to be separated in multiple files, for that matter. In Haskell, I can literally ask the editor to list me all functions that operate on type X. Even in C written with a modicum of coding discipline, 90% of the functions relevant to type X will be defined in X.h, wherein 100% of the functions in X.h are relevant to type X. (And the 10% of functions relevant to type X that aren't in X.h? Well, in Java, they also wouldn't be part of class X anyway.)

hrjet 12y ago

IMO apart from namespaces, the other biggest convenience provided by OO is inheritance. In some problem domains, there are naturally emerging inheritance hierarchies. And when you need it, manually coding virtual dispatch in non-OO languages is going to be hairy.

andrewstuart2 12y ago

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.

oblio 12y ago

Isn't also limiting the potentially boundless array of (mostly irrelevant) functions to relevant data types also relevant? I'd venture to say it is. Ooooh... that's a Point object - no way the AddAccount function does anything relevant with it! In OO you don't even actually need to think that since Point has a limited set of methods.

deleted 12y ago
[deleted]
sbov 12y ago
I'd be willing to bet that the Point object in any given language is going to have more methods that take it as an argument than methods the class itself has.
- oblio 12y ago
  True. But I still go looking for the "Point" class first. Then I start looking for things which accept "Point" parameters. Big difference from procedural programming languages.
  - colanderman 12y ago
    In C, I look in "point.h" first, then start looking for other things. Not really different.
- hrjet 12y ago
  A natural way to separate those two types of methods is: * methods that do something *to* a Point object * methods that do something *with* a Point object The former are better to be declared inside the Point object so that they have access to internal state. The latter shouldn't typically access internal state of the Point object. This separation can help immensely while analyzing a code base.
colanderman 12y ago
This applies to any language with static types. Or that allows code to be separated in multiple files, for that matter. In Haskell, I can literally ask the editor to list me all functions that operate on type X. Even in C written with a modicum of coding discipline, 90% of the functions relevant to type X will be defined in X.h, wherein 100% of the functions in X.h are relevant to type X. (And the 10% of functions relevant to type X that aren't in X.h? Well, in Java, they also wouldn't be part of class X anyway.)