Uncle Bob Martin

Ideally this would imply immutable objects IMO. Changes to objects are functional transformations producing a new object, not stateful updates to objects. Of course stateful updates have utility as well, such as atoms in Clojure but the more mutation is used the less functional

Functional programming does not require immutable objects, it only requires that all functions in the domain be referentially transparent. In practice this is often implemented with immutable data types but with powerful enough abstractions it need not be

amen, I just LOL when FP purists crap on objects, given that they are using them in every fiber of their own garments..

What do you mean? Can you show me a Haskell codebase full of objects?

An OOPL programmer has to figure out how to eliminate the possibility of observing an object in an inconsistent state. FPL programmers get that for free. Both are still working with objects. Perhaps OOPLs just missed the point?

If you want to control the lights at an intersection, state transitions are a requirement. The FP program has to change the lights just as much as the OOP program. There are plenty of tools for managing state transitions in any kind of programming language. FP is not exempt.