4 ms·

I grasped the concept of OOP pretty easily. Can't say the same about FP.

by p1esk 7y ago

naikrovek 7y ago
Because the OOP concept doesn't map to how a computer actually operates on data, and FP does much more. It's certainly much easier in a Functional language to optimize for the CPU cache and to support concurrency and parallelism. OOP was designed for humans, and not computers; of course it is going to be easier.
- AnimalMuppet 7y ago
  I strongly disagree. How a computer actually operates on data is the CPU's opcodes, which: 1) have no notion of what a function is, 2) are quite happy to deal with global variables, 3) are perfectly willing to mutate data anywhere, 4) are willing to branch to arbitrary locations. That's about as far from FP as you can get.
  - naikrovek 7y ago
    And OOP is closer? Are you saying CPUs are object oriented? Or maybe you just latched onto the comment about FP and decided to argue against it in isolation. I am saying that CPUs are NOT object oriented and that functional programming is closer to how a CPU operates than OOP is, and therefore much easier for a compiler (and a compiler author) to reason about and to optimize.
    - Jtsummers 7y ago
      Question: Which functional programming languages are you specifically referring to with that statement?
    - AnimalMuppet 7y ago
      > And OOP is closer? No. > Are you saying CPUs are object oriented? No. > Or maybe you just latched onto the comment about FP and decided to argue against it in isolation. Yes, because it was flat-out wrong. FP is not in any way closer to how a CPU operates. (I mean, the rest of your post had problems, too, but that one bit was glaringly wrong.) > I am saying that CPUs are NOT object oriented That I will agree with.
- Jtsummers 7y ago
  All programming languages were designed for humans and not computers, outside of assembly and machine code, and some higher level languages that are tightly coupled with a specific machine architecture. Computers are inherently procedural. Their code is inherently "unstructured". Structured Programming was developed for humans, for the maintenance and communication of programs by and to humans. And that's just basic procedural programming. Functional and OO programming are even more divorced from the underlying machine. And that's not a problem, that's a good thing for most programs that need to be written. EDIT: Actually, even assembly was designed for humans. It's just that there's usually a 1-to-1 mapping between an assembly language and the underlying machine code.
  - p1esk 7y ago
    Even machine code these days is pretty divorced from the corresponding hardware ops. A modern processor usually has to look up what to do when it receives a machine code instruction.
madhadron 7y ago
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.
proverbialbunny 7y ago
You could frame OOP as a single concept. OOP is making an abstraction that within that abstraction can store mutable state. Though, that doesn't really hit at all OOP has to offer. FP, on the other hand, is more like a set of tools. You can use many of those tools in many OOP languages. In this way FP is a lot like procedural programming paradigm, as it too is a set of tools. And that is why >I grasped the concept of OOP pretty easily. Can't say the same about FP. is a no. Not because FP is difficult, but because it isn't a singular object.
- p1esk 7y ago
  Ok. Can you give me an example of any FP objects/tools which are useful? By useful I mean it would make my life (as a coder of short research oriented programs) easier. Similar to how learning OOP made it easier to keep track of all the moving parts in my code?
  - proverbialbunny 7y ago
    One example is streaming. Streams allow for a near infinite array size to be processed, because it works on one element at a time as it comes in. Streams come from the FP world. From that function chaining originates from the FP world and is used in modern languages like Python quite heavily. You mentioned research, so a valid example of this is the difference between Spark and MapReduce. Spark was introduced to optimize processing large sets of data, by streaming it. MapReduce does not. For a more heavy example, a few data structures that are quite powerful come from the FP world. For example, this cppcon talk is introduces one, which gives near O(1) time for all uses (insert, delete, lookup, ...), and can be used in a thread safe way: https://youtu.be/sPhpelUfu8Q https://youtu.be/sPhpelUfu8Q

I grasped the concept of OOP pretty easily. Can't say the same about FP.

by p1esk 7y ago

I grasped the concept of OOP pretty easily. Can't say the same about FP.

Because the OOP concept doesn't map to how a computer actually operates on data, and FP does much more. It's certainly much easier in a Functional language to optimize for the CPU cache and to support concurrency and parallelism. OOP was designed for humans, and not computers; of course it is going to be easier.

AnimalMuppet 7y ago
I strongly disagree. How a computer actually operates on data is the CPU's opcodes, which: 1) have no notion of what a function is, 2) are quite happy to deal with global variables, 3) are perfectly willing to mutate data anywhere, 4) are willing to branch to arbitrary locations. That's about as far from FP as you can get.
- naikrovek 7y ago
  And OOP is closer? Are you saying CPUs are object oriented? Or maybe you just latched onto the comment about FP and decided to argue against it in isolation. I am saying that CPUs are NOT object oriented and that functional programming is closer to how a CPU operates than OOP is, and therefore much easier for a compiler (and a compiler author) to reason about and to optimize.
  - Jtsummers 7y ago
    Question: Which functional programming languages are you specifically referring to with that statement?
  - AnimalMuppet 7y ago
    > And OOP is closer? No. > Are you saying CPUs are object oriented? No. > Or maybe you just latched onto the comment about FP and decided to argue against it in isolation. Yes, because it was flat-out wrong. FP is not in any way closer to how a CPU operates. (I mean, the rest of your post had problems, too, but that one bit was glaringly wrong.) > I am saying that CPUs are NOT object oriented That I will agree with.
Jtsummers 7y ago
All programming languages were designed for humans and not computers, outside of assembly and machine code, and some higher level languages that are tightly coupled with a specific machine architecture. Computers are inherently procedural. Their code is inherently "unstructured". Structured Programming was developed for humans, for the maintenance and communication of programs by and to humans. And that's just basic procedural programming. Functional and OO programming are even more divorced from the underlying machine. And that's not a problem, that's a good thing for most programs that need to be written. EDIT: Actually, even assembly was designed for humans. It's just that there's usually a 1-to-1 mapping between an assembly language and the underlying machine code.
- p1esk 7y ago
  Even machine code these days is pretty divorced from the corresponding hardware ops. A modern processor usually has to look up what to do when it receives a machine code instruction.

madhadron 7y ago

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.

proverbialbunny 7y ago

You could frame OOP as a single concept. OOP is making an abstraction that within that abstraction can store mutable state. Though, that doesn't really hit at all OOP has to offer. FP, on the other hand, is more like a set of tools. You can use many of those tools in many OOP languages. In this way FP is a lot like procedural programming paradigm, as it too is a set of tools. And that is why >I grasped the concept of OOP pretty easily. Can't say the same about FP. is a no. Not because FP is difficult, but because it isn't a singular object.

p1esk 7y ago
Ok. Can you give me an example of any FP objects/tools which are useful? By useful I mean it would make my life (as a coder of short research oriented programs) easier. Similar to how learning OOP made it easier to keep track of all the moving parts in my code?
- proverbialbunny 7y ago
  One example is streaming. Streams allow for a near infinite array size to be processed, because it works on one element at a time as it comes in. Streams come from the FP world. From that function chaining originates from the FP world and is used in modern languages like Python quite heavily. You mentioned research, so a valid example of this is the difference between Spark and MapReduce. Spark was introduced to optimize processing large sets of data, by streaming it. MapReduce does not. For a more heavy example, a few data structures that are quite powerful come from the FP world. For example, this cppcon talk is introduces one, which gives near O(1) time for all uses (insert, delete, lookup, ...), and can be used in a thread safe way: https://youtu.be/sPhpelUfu8Q https://youtu.be/sPhpelUfu8Q