OOP definitely allows you to add both data abstraction and procedure abstraction. FP is opinionated concerning how one should abstract and OOP is fundamentally less opinionated - for good or ill (that is pretty much the debate).

> OOP definitely allows you to add both data abstraction and procedure abstraction.

No it doesn't, not pure, typed OOP [1]. Unless you introduce dynamic types, then neither is more opinionated because you can just cast or dispatch at whim.

[1] https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf

In the vast majority of OOP language, the object allows one to do virtually anything behind the scenes with a bit of construction (plus of course functional programming is opinionated. There are a whole variety of definitely bad practices an FP programmer will point to as being disallowed by the FP).

See: "Closures And Objects Are Equivalent" etc.

http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent

And

https://stackoverflow.com/questions/2497801/closures-are-poo...

Yes, because those objects are a fusion of OOP and ADTs. Pure OOP does not permit violating procedural abstraction.

To summarise, FP provides good reasoning in the small, and OO is needed in the large to orchestrate stateful services via protocols.

The paper that you're citing claims that "pure OOP" means "An object can only access other objects through their public interfaces". This feels like a very arbitrary definition to me, and one that does not correspond to what we deem OOP colloquially. Conversely, if the problem is "pure OOP", but most OOP that we actually use isn't "pure", then there's no problem.

Why is that arbitrary? Encapsulation is a core principle of OOP.

Re: there being no problem, that depends. Pure OOP has advantages and violating the properties often sacrifice some of those advantages.

> Encapsulation is a core principle of OOP.

That's exactly the assertion that I'd like substantiated. I don't think there's consensus on this. Sure, it's mentioned in the oft-cited "encapsulation, inheritance, polymorphism, abstraction" mantra - but so is inheritance, and yet prototype-based OO doesn't have it.

Personally, I would say that the only core principles of OOP are object identity (i.e. objects are distinguishable aside from their state), and polymorphism via dynamic dispatch. Everything else is optional.

There's a historical argument: encapsulation was in Cardelli's original object calculi, and part of every OO language of the time.

There's also a conceptual argument: dynamic dispatch and object identity both require encapsulation. What do you think you're dispatching or comparing equality on if not hidden state?