OOP vs. FP

OOP vs. FP(medium.com)

33 points by horrido 9 years ago | 29 comments

Pitarou 9 years ago |

I don’t wholly disagree with the article, but I think it overstates its case. In particular:

> Is there really so much difference between f(o), o.f(), and (f o)?

Yes, there is!

In the case of o.f(), o needs to know about f.

In the case of f(o), f needs to know about o.

trendia 9 years ago | |

Maybe I'm mistaken... but at least in C++ the implementation of Foo::Bar() is similar to Bar(Foo):

    Bar(Foo * foo); // how Foo::Bar() is implemented

So while Bar(Foo) could be passed as several ways:

    Bar(Foo foo);
    Bar(Foo &foo);
    Bar(Foo *foo);
    ....

there isn't really a huge distinction between the two except for syntax and locality within the source file. (That is, class methods are all defined in the class and can't be spread across multiple header files).

nailer 9 years ago | |

I don't see that as much difference.

fantasticsid 9 years ago | | |

I think the difference becomes easier to see when you need to add new data types vs new functions

http://wiki.c2.com/?ExpressionProblem

Pitarou 9 years ago | | |

Take a class C.

Alice extends class C with class A, which implements function a.

Bob extends class C with class B, which implements function b.

I have both Alice’s and Bob’s code, and I want to use both a and b. How can I do it?

Of course, there are ways to do it – notably multiple inheritance, if your language supports it – but the point is, in a functional language, this question never even arises. You just import the function definitions and use them, without ever having to think about the mechanics of it.

By the way, I’m not saying that this necessarily makes functional languages better (although I do tend to prefer them). I’m just pointing out that the difference is real.

cromwellian 9 years ago | |

Maybe it's best to think about this in a capabilities-security aspect.

'o' gives you capabilities to perform 'f'. 'o' can hide its data and only expose functions that it wishes.

With f(o), 'f' needs to be given permission to access 'o' internals.

girvo 9 years ago | |

In Nim, with its unified function call syntax, there is no difference between them, which is pretty neat.

serichsen 9 years ago |

Valid points, but not _the_ point. There is a big difference between allowing and supporting something.

OO languages _support_ hidden inputs and outputs as well as programming by mutation. They _allow_ programming in a functional style, but you will have to be inventive for it.

FP languages _support_ immutable values, referential transparency and all that. They _allow_ programming by mutation and hidden inputs and outputs, but you will have to be (sometimes very) inventive for it.

regulation_d 9 years ago | |

Exactly. Starting points matter. And for me, a starting point of "enforces immutable data" is a good one.

horrido 9 years ago | | |

Starting points matter, but this depends on the programming situation. That's why you use OOP or FP where it is most appropriate or suitable. Neither OOP nor FP is a panacea. Neither OOP nor FP is the universal programming tool.

horrido 9 years ago | |

Nothing prevents an object's methods from being referentially transparent. It just depends on how you choose to write them.

shady-lady 9 years ago |

hmm, not so sure I agree to that extent.

[To me,]

FP is more about nobody owning the data. Everything operating on all the data. (Mostly) All data exposed and accessible.

OOP is about certain classes owning data and limiting exposure to that data.

horrido 9 years ago | |

It has nothing to do with ownership. In FP, a function can only operate on data of a particular type. In OOP, a particular type (or class) gathers all the applicable functions (or methods) under one roof. Same difference.

shady-lady 9 years ago | | |

Well, not really.. In effect, your class owns the relevant piece of data that it operates on and only allows pre-defined operations on that data.

Maybe my point is better articulated by saying [to me,] functional programming is more data oriented than OOP.

noblethrasher 9 years ago |

A closure is a poor man's object, and an object is a poor man's closure: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

crimsonalucard 9 years ago |

Is this guy talking about OO as described by smalltalk? Because he says that objects are bags of functions, not data, but in languages like java, c# and c++ objects are bags of both.

noblethrasher 9 years ago | |

Yes, he is probably talking about Smalltalk-style OO:

https://medium.com/@richardeng/domo-arigato-mr-smalltalk-aa8...

He's also the subject of this article: https://thenewstack.io/can-man-spark-renaissance-smalltalk-p..., which made the front page of HN a while back (https://news.ycombinator.com/item?id=13642947)

horrido 9 years ago | |

It's Uncle Bob who says objects are bags of functions. And this is not specific to Smalltalk nor dynamic languages. In Java, C#, and C++, objects are still just bags of functions.

noblethrasher 9 years ago | | |

Java and C# allow you to expose mutable fields, so objects are not strictly (or even ordinarily) just bags of functions.

crimsonalucard 9 years ago | | |

Yeah but objects in those languages are also bags of data, which he explicitly said they are not.

dragonwriter 9 years ago | |

The C++ family of languages isn't really all that object-oriented; it's practically a different (static, class-oriented) paradigm that takes some inspiration from OOP (mostly from Smalltalk) but more from C's particular implementation of statically-typed procedural programming, as a result they are based around structs-enhanced-with-methods rather than proper objects.