What is lacking from most FP languages though are the higher level abstractions of message passing between objects not to mention taxonomies of objects aka classes.
It is crucial to note that strict types do not mean correct programs contrary to FP mythology.
Every type has its own track width. Doh.
The notion of pure functions relies upon not storing or accessing state to compupte.
Monads store state, thus the lie.
To provide the pure no state claim they have to store state, thus the lie, the deception, the con of FP.
Oh wait, you can't as you've not been informed. Now you can't claim ignorance of the central pure lie of FP.
"monads can be seen as layering "effects" on:
Maybe: partiality (uses: computations that can fail)
Either: short-circuiting errors (uses: error/exception handling)
 (the list monad): nondeterminism (uses: list generation, filtering, ...)
State: a single mutable reference (uses: state)
Reader: a shared environment (uses: variable bindings, common information, ...)
Writer: a "side-channel" output or accumulation (uses: logging, maintaining a write-only counter, ..)
Cont: non-local control-flow (uses: numerous)"
So the pretend pure functions are at the bottom of the call stack.
Link for the list of monads above and the quote, stackoverflow.com/a/8777358.
Smalltalk's messages "ifTrue:ifFalse" on the Boolean classes are pure functions.
Smalltalk systems have many pure functions written as methods on classes all over the system class library.
In OOP we're just not pedantic about it as we deal with the real world.
Untyped Lambda Calculus allows more freedom to move and is part of the ancestry of Smalltalk.
No cycles are allowed, no object A <-> B.
Many real world data structures require network graph connected objects.
An Invoice object is allowed to point at its invoice items via a collection but heaven help the PFD programmer, that invoice item isn't allowed a back pointer. Nope as it is evil in PFD/FP.
Why is meant by "disconnected"?
Data is defined, often in different systems, from Code.
No need for unnecessarily constrainted data.
Real work oriented systems need to deal appropriately with the real world requirements pragmatically.
In Functional Programming storing state is considered bad and evil as it violates the "pure math functional programming" model.
To live together these principles need a resolution.
That is fine as it is always their choice.