6 ms·

People say this, and I'm not sure it's actually true. People grasp some basic use of structs with methods on them pretty quickly and using that to do polymorphi

People say this, and I'm not sure it's actually true. People grasp some basic use of structs with methods on them pretty quickly and using that to do polymorphism. Most programmers I know haven't grasped how to use a system of message passing objects to make the semantics of the underlying language programmable at runtime.

DaiPlusPlus 7y ago
> Most programmers I know haven't grasped how to use a system of message passing objects to make the semantics of the underlying language programmable at runtime. Can you please elaborate on this? By “message passing” are you referring to ObjectiveC-style virtual calls - or to message-passing in the context of OOP loose-coupling for disseminating events (i.e. broadcasting) instead of using strong references to call event-handlers?
- madhadron 7y ago
  Objective-C's virtual calls are exactly the message passing I mean. They're a direct copy of Smalltalk's.
p1esk 7y ago
To me OOP is about using "templates" to create "objects", which map nicely to real world entities/concepts. So a class is like a function, but unlike a function it can do more than define an input to output mapping. It groups together multiple related functions and variables, and allows "objects" to exist and be interacted with. These "templates" can be hierarchical and/or have more than one "base template", combining all their "features". This type of thinking feels natural to model real world objects and tasks. The above is my "layman's" understanding of OOP (I've never taken programming classes, but I have been using OOP extensively in the code I write to do my machine learning research). Can someone describe FP in a similar manner to someone like me? Because every couple of years I stumble upon another "intro to FP", and it just does not click for me. When exactly should I use it? How "monads" or "functors", or whatever else is important in FP, map to the real world, and real tasks? Maybe I just don't write the type of code that would benefit from it.
- ryandrake 7y ago
  I feel the same way. As hobbies I like to work with my hands on things like carpentry and metalworking. OOP maps pretty well to how I think about accomplishing step by step tasks on physical objects: Step 1: Use this tool (instance of a class) to perform that modification (call a mutating method) to affect this workpiece (another class instance). Step 2: Now use that tool... So if I’m building a cabinet, my mind plans out something like: saw.cut(wood1); saw.cut(wood2); wood3 = glue_bottle.apply(wood1,wood2); sander.sand(wood3); Etc. I’ve always thought of a program as just a more elaborate series of step by step commands. Computer do this to this thing, now do that to that thing (which may, through a subroutine, mean doing other nested tasks). I can’t wrap my mind around accomplishing a step by step process with functional programming. Just haven’t made that mental leap yet, probably because I’m so used to thinking the other way.
  - dragonwriter 7y ago
    For a simple case like this with no diamond-shaped dependencies, the direct functional expression is inside-out rather than top-to-bottom: sand( sander, glue(bottle, cut(saw, wood1), cut(saw, wood2)))
    - username90 7y ago
      Now write that code with tools having durability. In OOP that is trivial and require no code changes elsewhere.
  - madhadron 7y ago
    > I’ve always thought of a program as just a more elaborate series of step by step commands...Just haven’t made that mental leap yet, probably because I’m so used to thinking the other way. Yes, it's a hard mental leap the first few times. And there's another leap to logic programming that is almost as large as the jump to functional programming. Perhaps a physics analogy would be useful. A physicist may use a local, kinematic view: the object is here and has this velocity, and this force on it, so in a fraction of an instant that will make it move this much, and in another fraction of an instant it will move this much more... A physicist may also use a global view: if I consider the set of all possible paths that start at point A and end at point B, what distinguishes the one an object will actually take? Both are useful, and things that are obvious in one are usually quite obscure in the other.

DaiPlusPlus 7y ago

> Most programmers I know haven't grasped how to use a system of message passing objects to make the semantics of the underlying language programmable at runtime. Can you please elaborate on this? By “message passing” are you referring to ObjectiveC-style virtual calls - or to message-passing in the context of OOP loose-coupling for disseminating events (i.e. broadcasting) instead of using strong references to call event-handlers?

madhadron 7y ago
Objective-C's virtual calls are exactly the message passing I mean. They're a direct copy of Smalltalk's.

p1esk 7y ago

To me OOP is about using "templates" to create "objects", which map nicely to real world entities/concepts. So a class is like a function, but unlike a function it can do more than define an input to output mapping. It groups together multiple related functions and variables, and allows "objects" to exist and be interacted with. These "templates" can be hierarchical and/or have more than one "base template", combining all their "features". This type of thinking feels natural to model real world objects and tasks. The above is my "layman's" understanding of OOP (I've never taken programming classes, but I have been using OOP extensively in the code I write to do my machine learning research). Can someone describe FP in a similar manner to someone like me? Because every couple of years I stumble upon another "intro to FP", and it just does not click for me. When exactly should I use it? How "monads" or "functors", or whatever else is important in FP, map to the real world, and real tasks? Maybe I just don't write the type of code that would benefit from it.

ryandrake 7y ago
I feel the same way. As hobbies I like to work with my hands on things like carpentry and metalworking. OOP maps pretty well to how I think about accomplishing step by step tasks on physical objects: Step 1: Use this tool (instance of a class) to perform that modification (call a mutating method) to affect this workpiece (another class instance). Step 2: Now use that tool... So if I’m building a cabinet, my mind plans out something like: saw.cut(wood1); saw.cut(wood2); wood3 = glue_bottle.apply(wood1,wood2); sander.sand(wood3); Etc. I’ve always thought of a program as just a more elaborate series of step by step commands. Computer do this to this thing, now do that to that thing (which may, through a subroutine, mean doing other nested tasks). I can’t wrap my mind around accomplishing a step by step process with functional programming. Just haven’t made that mental leap yet, probably because I’m so used to thinking the other way.
- dragonwriter 7y ago
  For a simple case like this with no diamond-shaped dependencies, the direct functional expression is inside-out rather than top-to-bottom: sand( sander, glue(bottle, cut(saw, wood1), cut(saw, wood2)))
  - username90 7y ago
    Now write that code with tools having durability. In OOP that is trivial and require no code changes elsewhere.
- madhadron 7y ago
  > I’ve always thought of a program as just a more elaborate series of step by step commands...Just haven’t made that mental leap yet, probably because I’m so used to thinking the other way. Yes, it's a hard mental leap the first few times. And there's another leap to logic programming that is almost as large as the jump to functional programming. Perhaps a physics analogy would be useful. A physicist may use a local, kinematic view: the object is here and has this velocity, and this force on it, so in a fraction of an instant that will make it move this much, and in another fraction of an instant it will move this much more... A physicist may also use a global view: if I consider the set of all possible paths that start at point A and end at point B, what distinguishes the one an object will actually take? Both are useful, and things that are obvious in one are usually quite obscure in the other.