Often in OOP the internal state of objects is modified. In FP on does not modify state, unless one does not find another way or performance issues really force one to do so, for example, if one had to copy huge objects and tge performance suffers noticably.
In OOP we often give objects as arguments, where we would give functions in FP, which is usually a simpler construct.
They main concept in FP is the function or closures and so on as first class citizens, while in many OOP lang (!) it is the object and functions are second class only.
Good FP support in a language requires good support for recursion in my opinion, to profit from elegant ways to express things and "what" not "how" style.
Many design patterns (Gang of 4) in OOP simply come naturally in FP or are circumvented with using functions as the main primitive and giving them as arguments and not mutating state. For example the decorator pattern or the visitor pattern.
So yes, in some ways OOP and FP are mutually exclusive, but not In some other ways.
In OOP we often give objects as arguments, where we would give functions in FP, which is usually a simpler construct.
They main concept in FP is the function or closures and so on as first class citizens, while in many OOP lang (!) it is the object and functions are second class only.
Good FP support in a language requires good support for recursion in my opinion, to profit from elegant ways to express things and "what" not "how" style.
Many design patterns (Gang of 4) in OOP simply come naturally in FP or are circumvented with using functions as the main primitive and giving them as arguments and not mutating state. For example the decorator pattern or the visitor pattern.
So yes, in some ways OOP and FP are mutually exclusive, but not In some other ways.