4 ms·

> The big advantage of OO is that it acts as a distillation of how humans think. With how widespread OO is now and in the last decades, how much it is taught a

by Dewie 12y ago

> The big advantage of OO is that it acts as a distillation of how humans think. With how widespread OO is now and in the last decades, how much it is taught and how important it is in a fair share of popular programming languages (or even mandatory, for all practical purposes), this point might just be a self-fulfilling prophecy (if I'm using that expression correctly).

seanmcdirmid 12y ago
The way OOP is taught often doesn't bring up object thinking. But if you believe it is not natural, try thinking mathematically (without nouns or names as unique aliasable identifiers). Or without isa or hasa relationships. Our minds have 50,000+ years of language expertise, and only a couple thousand for formal non linguistic equational reasoning (where things only have structure and are unnameable).
- swift 12y ago
  I'm not so sure. There's some truth to what you're saying, but by "is a", statically typed OO languages generally mean something much different than what we mean by that in human languages. I find OO's obsession with hierarchy and taxonomy to be profoundly unintuitive.
  - seanmcdirmid 12y ago
    There is much more to OOP than Java.
    - swift 12y ago
      Something like Smalltalk or Ruby is certainly closer to my preferences. The focus on taxonomy is definitely most obvious and most painful in languages with static typing and fewer dynamic features. Can you suggest an OO language that really avoids the issue, though? It seems inherent in the notion of inheritance to me, even interface-only inheritance. Something like Haskell's typeclasses or Rust's traits seems to me like an easier way to model concepts from the real world.
      - seanmcdirmid 12y ago
        Believe it or not, Scala can be quite powerful since it supports mixin-like traits. I'm not sure about "avoiding" taxonomy though, I find variants useful, but I also like to play with layers (think modularized features of variants). Type classes aren't reall OO, I mean, they allow for some non-nominal subtyping that meshes with purity. I would argue that OO is really about the names, and OO thinking is really just a way of naming everything in your problem, while type classes mostly keep with the name-free equations reasoning.
        tome 12y ago
        That's interesting. Could you say something more about OO being about naming everything?
        seanmcdirmid 12y ago
        Object thinking is about naming things, naming meta things, and then using those name to describe those relationships. E.g. Fido is a dog, and a dog is an animal because I said so. Names are incredibly useful as abstractions: I know Fred, if I see him wearing different clothes and a haircut, I know he is still Fred; my other friends can tell me things about Fred, fred can have a criminal history. This is only possible because Fred has a name, otherwise, he would just be a stateless blob. Note that nothing is really proven with names, just asserted. This is why theoreticians dislike them. Equational reasoning gets away from names by working purely with structure. Of course, we can apply labels to structure (since our brains are so reliant on names for reasoning), but they have no special meaning and we are careful not to let them bias the results. Most programs involve heavy doses of object thinking, even if the language is not specifically OOP. It takes a real genius (or a Vulcan...joking) like the high end haskell crowd (SPJ, Conal elliot, etc) to leverage equational reasoning where most would otherwise use object thinking.
        swift 12y ago
        I really need to check out Scala! Thanks for the reply. (And I'm also interested to hear more about OO as naming.)
- mtrimpe 12y ago
  Then again... capturing things with hierarchical, permanent, non-context dependent hasa / isa relationships is very, very far removed from how we've used language for the past 50k years.
  - seanmcdirmid 12y ago
    Can you give me an example? I'm at work right now in a hierarchical, permanent, non-context dependent environment and is-a, has-a relationships abound. We deal with the complexity of the world by organizing it into hierarchies.
    - mtrimpe 12y ago
      Language is incredibly fuzzy... and for good reason. Creating fixed structures that span across groups of people is incredibly hard. Just take a look at how much work/debate has gone into the taxonomy of life. Apart from that relationships are context dependent. I can have a father but if he passes away I still have one in some sense but not in another. I can also have ideas... or friends which can be mutual or not. Heck... even "I" isn't fixed. If I'm sleepwalking it's me but not really me. My point was: do you know of any OOP language which can fluently handle this without having the object metaphor break down?
      - seanmcdirmid 12y ago
        No language can encode exactly how we think. We aren't going to get there until we have hard machine intelligence (then we are programming anymore). But we definitely think with objects, and OOP languages are simply trying to exploit that (we can definitely debate about how well!). OO thinking has no problem with stateful reasoning, your father can be currently dead and previously alive.
- dragonwriter 12y ago
  > The way OOP is taught often doesn't bring up object thinking. But if you believe it is not natural, try thinking mathematically (without nouns or names as unique aliasable identifiers). Or without isa or hasa relationships. Is-a and Has-a relationships don't require class-based OO structures to express in a language. E.g., both membership in a abstract group sharing a common interface (is-a) and composition (has-a) relationships are readily expressed in FP languages like Haskell quite directly, or in languages that are more like traditional OO langauges but which separate interface from implementation rather than combining them as is done in class-based OO. The OO approach to programming, and thinking about domains, has broad utility, but the particulars of static, class-based OOP are not necessary to realize that utility.
  - seanmcdirmid 12y ago
    > but the particulars of static, class-based OOP are not necessary to realize that utility. The design goal of a OOPL is to support object thinking. FPL generally have other goals, and some of their design philosophies reject object thinking altogether. You'll often see lots of objects in ML or Scheme libraries; but the languages are not really optimized for this way of solving problems. Haskell, as a real pure FPL, is really the anti-thesis of object thinking. You cannot express nominal is-a relationships in Haskell very easily at all: it is all structural (and type classes don't get around that) and supports equational rather than name-based reasoning. You could add names to Haskell via GUIDs or impure language features. This is not really the way to program in Haskell, however.
    - dragonwriter 12y ago
      > The design goal of a OOPL is to support object thinking. Yes, my point is that class-based OOPLs aren't the only way to do that (and in some respects create some unnecessary problems with that), which is among the reasons that many newer languages -- even ones that are not particularly functional languages, and which have OO roots -- are not class-based.
      - seanmcdirmid 12y ago

by Dewie 12y ago

seanmcdirmid 12y ago

The way OOP is taught often doesn't bring up object thinking. But if you believe it is not natural, try thinking mathematically (without nouns or names as unique aliasable identifiers). Or without isa or hasa relationships. Our minds have 50,000+ years of language expertise, and only a couple thousand for formal non linguistic equational reasoning (where things only have structure and are unnameable).

swift 12y ago
I'm not so sure. There's some truth to what you're saying, but by "is a", statically typed OO languages generally mean something much different than what we mean by that in human languages. I find OO's obsession with hierarchy and taxonomy to be profoundly unintuitive.
- seanmcdirmid 12y ago
  There is much more to OOP than Java.
  - swift 12y ago
    Something like Smalltalk or Ruby is certainly closer to my preferences. The focus on taxonomy is definitely most obvious and most painful in languages with static typing and fewer dynamic features. Can you suggest an OO language that really avoids the issue, though? It seems inherent in the notion of inheritance to me, even interface-only inheritance. Something like Haskell's typeclasses or Rust's traits seems to me like an easier way to model concepts from the real world.
    - seanmcdirmid 12y ago
      Believe it or not, Scala can be quite powerful since it supports mixin-like traits. I'm not sure about "avoiding" taxonomy though, I find variants useful, but I also like to play with layers (think modularized features of variants). Type classes aren't reall OO, I mean, they allow for some non-nominal subtyping that meshes with purity. I would argue that OO is really about the names, and OO thinking is really just a way of naming everything in your problem, while type classes mostly keep with the name-free equations reasoning.
      - tome 12y ago
        That's interesting. Could you say something more about OO being about naming everything?
        seanmcdirmid 12y ago
        Object thinking is about naming things, naming meta things, and then using those name to describe those relationships. E.g. Fido is a dog, and a dog is an animal because I said so. Names are incredibly useful as abstractions: I know Fred, if I see him wearing different clothes and a haircut, I know he is still Fred; my other friends can tell me things about Fred, fred can have a criminal history. This is only possible because Fred has a name, otherwise, he would just be a stateless blob. Note that nothing is really proven with names, just asserted. This is why theoreticians dislike them. Equational reasoning gets away from names by working purely with structure. Of course, we can apply labels to structure (since our brains are so reliant on names for reasoning), but they have no special meaning and we are careful not to let them bias the results. Most programs involve heavy doses of object thinking, even if the language is not specifically OOP. It takes a real genius (or a Vulcan...joking) like the high end haskell crowd (SPJ, Conal elliot, etc) to leverage equational reasoning where most would otherwise use object thinking.
      - swift 12y ago
        I really need to check out Scala! Thanks for the reply. (And I'm also interested to hear more about OO as naming.)
mtrimpe 12y ago
Then again... capturing things with hierarchical, permanent, non-context dependent hasa / isa relationships is very, very far removed from how we've used language for the past 50k years.
- seanmcdirmid 12y ago
  Can you give me an example? I'm at work right now in a hierarchical, permanent, non-context dependent environment and is-a, has-a relationships abound. We deal with the complexity of the world by organizing it into hierarchies.
  - mtrimpe 12y ago
    Language is incredibly fuzzy... and for good reason. Creating fixed structures that span across groups of people is incredibly hard. Just take a look at how much work/debate has gone into the taxonomy of life. Apart from that relationships are context dependent. I can have a father but if he passes away I still have one in some sense but not in another. I can also have ideas... or friends which can be mutual or not. Heck... even "I" isn't fixed. If I'm sleepwalking it's me but not really me. My point was: do you know of any OOP language which can fluently handle this without having the object metaphor break down?
    - seanmcdirmid 12y ago
      No language can encode exactly how we think. We aren't going to get there until we have hard machine intelligence (then we are programming anymore). But we definitely think with objects, and OOP languages are simply trying to exploit that (we can definitely debate about how well!). OO thinking has no problem with stateful reasoning, your father can be currently dead and previously alive.
dragonwriter 12y ago
> The way OOP is taught often doesn't bring up object thinking. But if you believe it is not natural, try thinking mathematically (without nouns or names as unique aliasable identifiers). Or without isa or hasa relationships. Is-a and Has-a relationships don't require class-based OO structures to express in a language. E.g., both membership in a abstract group sharing a common interface (is-a) and composition (has-a) relationships are readily expressed in FP languages like Haskell quite directly, or in languages that are more like traditional OO langauges but which separate interface from implementation rather than combining them as is done in class-based OO. The OO approach to programming, and thinking about domains, has broad utility, but the particulars of static, class-based OOP are not necessary to realize that utility.
- seanmcdirmid 12y ago
  > but the particulars of static, class-based OOP are not necessary to realize that utility. The design goal of a OOPL is to support object thinking. FPL generally have other goals, and some of their design philosophies reject object thinking altogether. You'll often see lots of objects in ML or Scheme libraries; but the languages are not really optimized for this way of solving problems. Haskell, as a real pure FPL, is really the anti-thesis of object thinking. You cannot express nominal is-a relationships in Haskell very easily at all: it is all structural (and type classes don't get around that) and supports equational rather than name-based reasoning. You could add names to Haskell via GUIDs or impure language features. This is not really the way to program in Haskell, however.
  - dragonwriter 12y ago
    > The design goal of a OOPL is to support object thinking. Yes, my point is that class-based OOPLs aren't the only way to do that (and in some respects create some unnecessary problems with that), which is among the reasons that many newer languages -- even ones that are not particularly functional languages, and which have OO roots -- are not class-based.
    - seanmcdirmid 12y ago