There actually is a big difference between o.f() and f(o)/(f o) (but there isn’t a huge difference between f(o) and (f o)). In the case of o.f(), the “function” is tightly coupled to the data, whether that data is state or a record or whatever. Doing this restricts the ability to make the function generic and operate on more generic typeclasses of similar data. You can use OO inheritance to create hierarchies of abstract classes and interfaces, but then you run into the diamond problem and you can only rationally inherit from one parent type per class if you want to be safe, and also bear in mind that shoving an object into a new hierarchy when requirements change is hard.

FP languages don’t suffer from this, and can define their functions generically to operate on all data that has the required characteristics precisely because they’re not tied to the data they operate on, and the classes of the data they accept are based on the mathematical properties of the operations that can be performed on that data, not on the arbitrary human concepts that OOP objects tend to be modeled after. Try implementing the monadic “bind” function, or the applicative “apply” function in C++ and Java. If you can do it, it’s super complicated to do so, but in Haskell it’s dead easy, and making my data an instance of the Monad or Applicative type classes is also dead easy if the operations on that data truly apply to the Monad and Applicative laws.

Really, the debate shouldn’t be about the Java/C++ model of OOP vs FP, as I’ve been noticing the trend is that consensus is converging on the community recognizing that Java-style OOP gets in your way more than it helps you. The better debate would be between the Erlang/Smalltalk style of OOP which actually encourages the proper breaking-up and encapsulation of state via message passing. I’ve used that paradigm in the past via Scala’s Akka framework, and found it to be truly helpful in the design of my code. More than I can say about the XML hell the Java DI frameworks put me through.