
OOP vs. FP - horrido
https://medium.com/@richardeng/oop-vs-fp-1a3da34d2030
======
Pitarou
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.

~~~
nailer
I don't see that as much difference.

~~~
Pitarou
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.

~~~
horrido
Inheritance is not a strict requirement of OOP. In OOP, you can always use
composition, in which case the question also never arises.

Inheritance is there _if you need it_. It's an available option.

~~~
BoiledCabbage
Yes, but in common discussion, noone when talking about OOP is referring to
inheritence-less OOP. No common programming language uses it, few to no
programmers practice it. OOP/w inheritance is the default item being
discussed.

~~~
horrido
And why is "common discussion" technically relevant? This is not a fault of
OOP but of education.

~~~
BoiledCabbage
You're talking about about OOP-B, everyone here is talking about OOP-A. OOP-B
isn't really a part of what's being discussed.

Anyone can bring it up, but "education" isn't relevant here. It's not what was
discussed in the article, or the comments.

~~~
nailer
As neither of you, I'm talking about OOP. Nobody's limiting the discussion to
composition or inheritance. Otherwise we'd be talking about how 'inheritance
sucks' rather than 'OOP sucks'.

------
serichsen
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
Exactly. Starting points matter. And for me, a starting point of "enforces
immutable data" is a good one.

~~~
horrido
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_.

------
shady-lady
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
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
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.

~~~
horrido
The word "own" is pretty meaningless. What does "own" even mean? Classes and
objects (thought of as "types") are an organizing principle for organizing
your functions. If you didn't organize them in this manner, then you'd have
_the same functions_ that operate on _the same data types_ , only they're
scattered everywhere, just like in functional programming.

~~~
newen
> the same functions that operate on the same data types, only they're
> scattered everywhere

???

OO is different because you have things like private variables. Meaning that
only methods of an object's class can access the variable. So you now have a
special group of functions that can access the variable. FP is not like that.

------
noblethrasher
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...](http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/msg03277.html)

------
crimsonalucard
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.

~~~
horrido
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
Java and C# allow you to expose mutable fields, so objects are not strictly
(or even ordinarily) _just_ bags of functions.

