4 ms·

FP vs. OO

20 points by PuffinBlue 9y ago

OtterCoder 9y ago
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.
millstone 9y ago
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/CookOOPvsADT90.pdf http://www.cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT... (PDF!)
smadge 9y ago
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.
tincholio 9y ago
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.
mannykannot 9y ago
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.
enz 9y ago
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?

20 points by PuffinBlue 9y ago

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.

millstone 9y ago

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/CookOOPvsADT90.pdf http://www.cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT... (PDF!)

smadge 9y ago

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.

tincholio 9y ago

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.

mannykannot 9y ago

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.

enz 9y ago

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?