OOP vs. Functional Programming (2014)

The statements are correct but the conclusion is backwards. The defining characteristic of OOP is that hidden state. Passing functions around is done all the time in functional languages.

> The bottom, bottom line here is simply this. OO programming is good, when you know what it is.

Ehhhh nope. The idea that you need "function pointers" to do polymorphism is confusing one particular implementation technique in one particular (frankly, bad) language for some universal rule. You can do polymorphism perfectly well without needing hidden mutable state - and when you do, life is generally better.

If all you have are singleton objects with static functions and no private data attributes, then I agree, but it’s also meaningless because such objects are very sincerely unrelated to anything from OOP. They are just stateless buckets of functions, which is more like a module than an object.

This is actually quite a good way to program in many cases. You can do it in Scala by only defining companion objects and never the actual class that it would correspond to (except for occasional cases where you need case classes or structural typing). You can do this in Python by just writing modules with no classes, and either use primitive data structures (list, set, dict, tuple, etc) for all your data, or else use absolutely minimal namedtuples.

I’d say this way of programming is almost totally FP and has hardly anything but superficial connections to OOP, which I think undermines the author’s point.

You can always claim it’s a semantic difference and different people mean different things with certain words. IMO that’d be disingenuous here. Any type of OOP that just uses objects as buckets of functions with no private data attributes is really just FP.

As soon as you add private data attributes whose values can break referential integrity of the object’s function calls, then it’s game over for FP and you’re in total OOP land.

That said, the post is a windy road with some dead-ends. Lots of statements that are highly contestable (see other top-level comments for examples).

So here is, IMO, the important take-away from the post on what's novel/unique/significant about the combination of abstraction/program design/programming techniques we call oop:

> In most software systems when one function calls another, the runtime dependency and the source code dependency point in the same direction. The calling module depends on the called module. However, when polymorphism is injected between the two there is an inversion of the source code dependency. The calling module still depends on the called module at run time. However, the source code of the calling module does not depend upon the source code of the called module. Rather both modules depend upon a polymorphic interface. This inversion allows the called module to act like a plugin.

This is a particular programming style. The author calls it "polymorphism", but that's far too large a label. The paragraph above is specific way of using polymorphism. This sort of programming style can be done in functional languages, but I think it's fair to say that 1) OOP did it first, and 2) OOP provides the most natural setting for thinking about what's going on in these sort of "plugin architectures".

https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html

Not that it adds any value, it's exactly as confused and pointless. Uncle Bob is getting old. He tries to find defining characteristics of OO, and ends up talking gibberish:

> The behavior [of o.f()] is dependent upon the type of o. i.e. f is polymorphic.

Nope, behavior of a "polymorphic" invocation depends on the value of the 'o' argument. (Types don't exist at runtime.) This happens all the time in FP, where passing around functions is normal.

> The mechanism of polymorphism must not create a source code dependency from the caller to the callee.

That's called a higher order function. You pass a function from module A to a HOF from module B. B ends up calling into A without a source code dependency. Big deal.

> What is FP? > referential transparency

Lispers would object. My take on it is that the essence of FP is higher order functions. If you don't have them, you need Design Patterns instead. If you do have HOFs, you don't see why anyone would bother with OO.

Bottom line: OO doesn't exist. It's just pointless jargon that only exists to make a difference without a distinction (e.g. between Smalltalk and Scheme), and possibly to sell books and Clean Code seminars.

The important concept is "single assignment". This is where values are initialized at creation and never changed. Go, which is an imperative language, favors single assignment. Functional programming is a form of single assignment.

Single assignment in an imperative syntax has some advantages over a pure functional form. Values have names, which helps when reading code. You can use the same value twice. It's functional programming without the cult.

The downside of single assignment is that you're frantically creating and discarding values. Underneath, the machine is imperative. So you need compiler support for efficient creation and discarding of values. LISP spends a lot of time creating and discarding values, then garbage collecting them. So do Javascript, Python, etc. Vast amounts of effort have gone into making that efficient, and today it's not a big problem. Rust goes even further, handling most of that overhead at compile time.

OO is very much about state, and that's the fundamental difference between non-FP languages and FP.

    a1 = object.f(b);
    a2 = object.f(b);

It also doesn't matter if your language implements OO in terms of message passing (Smalltalk, Erlang) or method calling (Java, C#, ...).

Variables in functional languages are variables in the sense of mathematical variables, i.e. they can take on multiple possible values. They don't need to change from one minute to the next to be true variables.

> Objects are bags of functions, not bags of data.

That might be an ideal case, but it is not reality. Pretty much every OO language has both of them combined.

> Is there really so much difference between f(o), o.f(), and (f o)? Are we really saying that the difference is just about the syntax of a function call?

Yes, there is.

Try doing a compose function with the OOP / member expression syntax.

Here it is in JS using FP syntax:

const compose = (...fns) => fns.reduce((f, g) => (...args) => f(g(...args)))

It would be even shorter in Haskell.

Try doing long division with Roman numerals.

Syntax is the structure behind mental representations and mental representations have tremendous power in expanding the physical limits of thought in the brain.

> The overriding difference between a functional language and a non-functional language is that functional languages don’t have assignment statements.

The overriding difference between FP and OOP languages is that the unit of composition and abstraction is the function or object, respectively.

That is just silly. I'd be willing to swallow the following revised version, in the context of immutable programming: "classes are bags of functions, not bags of data."

An object (class instance) is then just a datum which serves as a domain value to these functions. Given that domain value, each function in that bag-of-functions class produces a range value: and that bag of range values comprises the properties of the object.

Under traditional mutable OOP, those functions are impure in ways that logically require the object-datum to carry a representation of state somehow.

And anyway, since functions are data (being first class values), any bag of functions is necessarily a kind of bag of data.

Functional languages by design require better type systems that can accommodate more forms parametric polymorphism.

OPP traditionally encouraged the use of ad-hoc polymorphism (via classes) over parametric polymorphism (via generics). OPP languages generally also make it easy to perform Ad-hoc polymorphism at run-time with dynamic dispatch some languages even use dynamic dispatch by default.

TLDR: FP and OPP both have polymorphism. FP encourages parametric polymorphism. OPP encourages ad-hoc polymorphism.