3 ms·

This is just an emotional appeal. You can equally have "layers" of many dependant functions that have tedious flows of data obfuscating what's important to see.

This is just an emotional appeal. You can equally have "layers" of many dependant functions that have tedious flows of data obfuscating what's important to see. That aside, I'm curious about your comment on "certain problems just don't map cleanly onto OOP" FP and OOP are both Turing complete, which kind of problems you think "just don't map cleanly onto OOP"?

AnimalMuppet 12y ago
Things that are equivalent in theory are not necessarily equivalent in practice. For instance, think about Green's, Stokes', and Gauss's Theorems in vector calculus. They say that the integral of a function over the boundary of a region is equal to the integral of a derivative of the function over the whole region. They're equal; you can't get much more equivalent than that. But in practice, one of the integrals is often easier to do than the other, and so these theorems are used in practice to transform a hard problem into an easier one. Both FP and OOP are Turing complete. But in practice, certain problems may be easier to program in one approach or the other. If I were writing a numerical analysis package, the functional approach might work better. If I were writing an event-driven embedded system, I'd expect that OOP would do more for me than FP.
- angersock 12y ago
  Oh, that's absolutely true--but in OOP as practiced with deep inheritance trees (as distinct from, say, actors with internal functional implementations), it's not just possible but indeed is the preferred way of doing things. I'm not saying that it is wrong or even unnecessary--but the parent criticism was that it seemed more complicated than it had to be, and that it could often be more important to look at the data instead of the objects. I agree with that criticism. As for problems, I'll agree with my sibling poster--just because two things are academically equivalent doesn't mean that they are practically equivalent. Consider the link to Acton's talk...a lot of the testing and method calls are redundant or can be pulled out at a higher level, and encapsulation doesn't really win you anything because you know the problem domain concretely. Numerical code is another case where OOP doesn't quite get you there. If you're just finding the average of a list of numbers, is it more sensible to have a function which maps elements of the space of lists of numbers into a space of scalars (which happen to be averages), or to have a list of numbers object that happens to know how to answer the "what is your average" message? Now, let's say you wanted to represent a new space only of elements consisting of averages plus some offset. That's again trivial in a functional language with currying, but in OOP is kind of awkward. The reason we like functions is because they represent a straightforward mapping from one space to another, and can be implemented very performantly. OOP principles, especially encapsulation, require that a function cannot know about the internals of the object it's working with, because it should be able to be changed out at a moment's notice. It is also because of the requirement of functional programming to know concretely the details of the things passed into them that we see such demand for static and strongly-typed and immutable systems.

AnimalMuppet 12y ago

Things that are equivalent in theory are not necessarily equivalent in practice. For instance, think about Green's, Stokes', and Gauss's Theorems in vector calculus. They say that the integral of a function over the boundary of a region is equal to the integral of a derivative of the function over the whole region. They're equal; you can't get much more equivalent than that. But in practice, one of the integrals is often easier to do than the other, and so these theorems are used in practice to transform a hard problem into an easier one. Both FP and OOP are Turing complete. But in practice, certain problems may be easier to program in one approach or the other. If I were writing a numerical analysis package, the functional approach might work better. If I were writing an event-driven embedded system, I'd expect that OOP would do more for me than FP.

angersock 12y ago
Oh, that's absolutely true--but in OOP as practiced with deep inheritance trees (as distinct from, say, actors with internal functional implementations), it's not just possible but indeed is the preferred way of doing things. I'm not saying that it is wrong or even unnecessary--but the parent criticism was that it seemed more complicated than it had to be, and that it could often be more important to look at the data instead of the objects. I agree with that criticism. As for problems, I'll agree with my sibling poster--just because two things are academically equivalent doesn't mean that they are practically equivalent. Consider the link to Acton's talk...a lot of the testing and method calls are redundant or can be pulled out at a higher level, and encapsulation doesn't really win you anything because you know the problem domain concretely. Numerical code is another case where OOP doesn't quite get you there. If you're just finding the average of a list of numbers, is it more sensible to have a function which maps elements of the space of lists of numbers into a space of scalars (which happen to be averages), or to have a list of numbers object that happens to know how to answer the "what is your average" message? Now, let's say you wanted to represent a new space only of elements consisting of averages plus some offset. That's again trivial in a functional language with currying, but in OOP is kind of awkward. The reason we like functions is because they represent a straightforward mapping from one space to another, and can be implemented very performantly. OOP principles, especially encapsulation, require that a function cannot know about the internals of the object it's working with, because it should be able to be changed out at a moment's notice. It is also because of the requirement of functional programming to know concretely the details of the things passed into them that we see such demand for static and strongly-typed and immutable systems.