4 ms·

I agree that object orientation is a psychological success, but I think it's more for linguistic reasons than anything else. Our speech and thinking are organi

I agree that object orientation is a psychological success, but I think it's more for linguistic reasons than anything else. Our speech and thinking are organized into things, attributes, and actions. "The stove heats the water." An object performing an action on another object (a direct object, in parts of speech), changing the state of the direct object. So when we code this, it makes sense naturally to write something that is readable in human terms: stove.heat(water); This makes code easier to reason about and easier to go back to later. Hopefully, our code reads like the computer- and human-readable literature it is.

k__ 12y ago
But this simple example is also solvable with infix functions.
- asuffield 12y ago
  I don't think there is a particular reason why OO became popular here. There are several ways to do it, the choice between them is fairly close to arbitrary, and one of them became popular. While I'm no fan of OO as a dogmatic solution to every problem, the differences between it and any other reasonable approach are small for most problems, compared to the complexity of solving the problem itself.
  - waps 12y ago
    The difference between OO and most other approaches is that OO very strongly encourages you to raise the abstraction level of your code. Hackers hate this, because small segments of code that look near-identical can do vastly different or complex things and lots can go wrong in there. Also, the higher you go in abstraction, the more subtle the code becomes, the more important differences in meaning originate from very small differences in source code. Take a haskell monad chain and try to explain the sequence of 2 statements ... it takes 2 minutes of thought to figure it out. But of course those 2 statements do much more than 100 lines of C can do. And of course bad programmers hate this, because you have to learn abstractions. It depends on what you're doing. If you're writing a big application, something to be supported over the long term that isn't trivial, then OO is most definitely the way to go. If you're hacking something together that won't last the week, raising abstraction level will only stand in your way. If you're planning to rewrite the core of the application on a monthly basis, OO, and any other kind of abstraction, will make life very hard on you.
themartorana 12y ago
I think this is why Elixir's pipe syntax spoke to me while hacking on it yesterday. It puts the subject first, which has that human-readable bit to it. I've been writing code in myriad languages for 15+ years, but that doesn't make me impervious to what seems "obvious" or intuitively "proper" to my brain, organization-wise. This organization of language in this fashion is English-specific though. I wonder what feels intuitive to non-English (or non-Romantic) speakers - is it OO as well, or something else?
- seanmcdirmid 12y ago
  All natural human languages are noun based having subjects and objects (in the POS sense). Verbs never stand alone.
  - themartorana 12y ago
    Of course. I more meant the difference between: "The table is red." and "Red is the color of the table."
  - sbov 12y ago
    Some languages put verbs first though. In which case it seems like functional programming languages might make the most sense to them.
    - _asummers 12y ago
      Which spoken languages do this, out of curiosity? Edit: https://en.wikipedia.org/wiki/Verb%E2%80%93subject%E2%80%93object https://en.wikipedia.org/wiki/Verb%E2%80%93subject%E2%80%93o... Cool.
      - hrjet 12y ago
        Example of verb first: RTFA :)
        randallsquared 12y ago
username56283 12y ago
What (from a code organization perspective) might work better in practice is: water.heat(stove); because it's the water that's being changed and change should be encapsulated. On the other hand, the stove may also change in the process. In fact, the water and the stove do things to each other. Then what makes either of the two options more appropriate? Similar issues arise with a method called sendMessage; is the object having this method now supposed to send a message or to receive a message?
- sbov 12y ago
  What we actually need is to be able to use different heating algorithms dynamically. To achieve this we will use the strategy pattern, so you end up with: heatingStrategy.heat(water, stove);
  - username56283 12y ago
    What methods is this heating strategy going to call on water and stove? Consider for example that the stove builds up rust. Therefore it needs to know the properties of what's inside. Is the heating strategy going to tell it that?

k__ 12y ago

But this simple example is also solvable with infix functions.

asuffield 12y ago
I don't think there is a particular reason why OO became popular here. There are several ways to do it, the choice between them is fairly close to arbitrary, and one of them became popular. While I'm no fan of OO as a dogmatic solution to every problem, the differences between it and any other reasonable approach are small for most problems, compared to the complexity of solving the problem itself.
- waps 12y ago
  The difference between OO and most other approaches is that OO very strongly encourages you to raise the abstraction level of your code. Hackers hate this, because small segments of code that look near-identical can do vastly different or complex things and lots can go wrong in there. Also, the higher you go in abstraction, the more subtle the code becomes, the more important differences in meaning originate from very small differences in source code. Take a haskell monad chain and try to explain the sequence of 2 statements ... it takes 2 minutes of thought to figure it out. But of course those 2 statements do much more than 100 lines of C can do. And of course bad programmers hate this, because you have to learn abstractions. It depends on what you're doing. If you're writing a big application, something to be supported over the long term that isn't trivial, then OO is most definitely the way to go. If you're hacking something together that won't last the week, raising abstraction level will only stand in your way. If you're planning to rewrite the core of the application on a monthly basis, OO, and any other kind of abstraction, will make life very hard on you.

themartorana 12y ago

I think this is why Elixir's pipe syntax spoke to me while hacking on it yesterday. It puts the subject first, which has that human-readable bit to it. I've been writing code in myriad languages for 15+ years, but that doesn't make me impervious to what seems "obvious" or intuitively "proper" to my brain, organization-wise. This organization of language in this fashion is English-specific though. I wonder what feels intuitive to non-English (or non-Romantic) speakers - is it OO as well, or something else?

seanmcdirmid 12y ago
All natural human languages are noun based having subjects and objects (in the POS sense). Verbs never stand alone.
- themartorana 12y ago
  Of course. I more meant the difference between: "The table is red." and "Red is the color of the table."
- sbov 12y ago
  Some languages put verbs first though. In which case it seems like functional programming languages might make the most sense to them.
  - _asummers 12y ago
    Which spoken languages do this, out of curiosity? Edit: https://en.wikipedia.org/wiki/Verb%E2%80%93subject%E2%80%93object https://en.wikipedia.org/wiki/Verb%E2%80%93subject%E2%80%93o... Cool.
    - hrjet 12y ago
      Example of verb first: RTFA :)
      - randallsquared 12y ago

username56283 12y ago

What (from a code organization perspective) might work better in practice is: water.heat(stove); because it's the water that's being changed and change should be encapsulated. On the other hand, the stove may also change in the process. In fact, the water and the stove do things to each other. Then what makes either of the two options more appropriate? Similar issues arise with a method called sendMessage; is the object having this method now supposed to send a message or to receive a message?

sbov 12y ago
What we actually need is to be able to use different heating algorithms dynamically. To achieve this we will use the strategy pattern, so you end up with: heatingStrategy.heat(water, stove);
- username56283 12y ago
  What methods is this heating strategy going to call on water and stove? Consider for example that the stove builds up rust. Therefore it needs to know the properties of what's inside. Is the heating strategy going to tell it that?