
FP vs. OO - PuffinBlue
http://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html
======
millstone
The notion that "OO is polymorphism, FP is referential transparency" are
caricatures that annoy more than inform. Let's try to avoid that reduction.

One better reduction is OO as objects / FP as abstract data types per Cook's
well-known paper [1]. This argues that the key difference is when the
transition from abstract to concrete happens. The ADT approach is to do this
in the "observations", e.g pattern matching destructuring. But objects do this
in the "constructors", the class that gets set when the object is created.

In this view objects and ADTs (OO and FP) are competing, not not orthogonal.
Concretely you have to decide whether your C function switches on a tag, or
dispatches through a vtable. Which paradigm to prefer depends on the
properties you want from your model: dynamic extensibility, efficiency,
security, etc. are all considerations.

1:
[http://www.cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT...](http://www.cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT90.pdf)
(PDF!)

------
smadge
The author provides the example

    
    
      o.f()
      f(o)
    

and states that o.f() implies that f is polymorphic while f(o) implies a
source code dependency on a particular function f. They conclude objected
oriented is polymorphic, while functional is referentially transparent.

This is not true. In the functional case of f(o), o could be a value with a
type which is an instance of a type class which must define a function f. In
which case f is a polymorphic function. Comparably to how o.f() implies o is a
type (ie a class) which implements an interface that requires the class
implement a method f. However in the function case we get polymorphism AND
referential transparency. Whereas in the object oriented case we have no
garauntees about referential transparency.

------
mannykannot
I do not dispute the author's thesis that OO and FP can be combined
synergistically, but I don't find the specific arguments convincing.

In the author's characterization of OO, it seems strange that a bit of
syntactic sugar would make a profound difference to the semantics of programs,
and on closer inspection, it doesn't.

The author claims that with f(o), the caller has a dependency on the callee
that does not exist in the OO version o.f(), but of course, in either case,
the caller has a dependency on the callee doing the same right thing. There
are multiple approaches to assigning some sort of confidence to the
proposition that the program design satisfies this dependency, and an unending
debate over which is best, but none of them depend on the syntax of the call.
It doesn't even imply a specific implementation style, as there are several
languages, some OO and some not, in which f(o) might be implemented as
different functions for different types.

Pattern matching in fp is widely regarded as a feature.

------
OtterCoder
I may be confused about the thrust of this article, but I don't like
polymorphism. Independent of my appreciation for FP, I hate when I have to do
a bit of code in Java or similar languages, because instead of manipulating
dumb data, I have to learn 10,000 micro-APIs.

I would much rather have a short list of simple, powerful functions, that
operate over sequences. Array Oriented, if you will, or perhaps even Map
Oriented. If you need to construct a full name from an object, whether it's a
user or a client, or a character, or a cat or whatever, that can be passed
quickly over my lists to return the relevant strings.

This function-and-array style of programming forces you to standardize your
data formats and types across your program, and is easily tested. While the OO
approach allows you to indulge a thousand different quirks of naming and style
and logic, that will take far longer to test, and will likely still have
quirks and inconsistencies.

------
enz
I don't know if it's very accurate to say "f(o) is like o.f()". I think this
depends on the language and the way it deals with methods.

For example, Python makes this explicit: the first argument of a Python method
is `self`, which is nothing more than an object. The first argument has
nothing special, and its name is `self` only by convention. So, in Python,
yes, maybe we can say "f(o) another syntax for o.f()" and the signature of f
is `f(my_obj : MyObject)`, not f().

So, in some way, a Python method has the potential to have "pure" scope just
like a regular FP function: You have no special global reference like `this`,
you only have what you have passed to the function.

But what about other OOP languages ? Do they have the same semantic?

------
tincholio
I really don't know why people keep paying attention to this guy. He's clearly
very good at selling himself but not much more. The silly explanation of
polymorphism based on syntax, makes it seem like he's never heard of multiple
dispatch, or typeclasses.

