There's some muddiness in the terminology here -- OOP is really a design style, and "OOP languages" are generally imperative languages that have sematics that encourage OOP design. It is very possible, even encouraged, to represent state as "Objects" in many functional languages; it's just not really enforced by the language itself.
A good example of this are the object systems in Scheme and Common Lisp (which are less strictly Functional (note the capital F in that word) then something like Haskell).
I asked mainly because of the terminology. I read the primer of how to code OOP in plain C about a decade ago, so I knew that the paradigm definitely can be applied to “non OOP languages”, but I wasn’t sure whether the term “functional programming” allows this or not for some obscure academic reasons. How I coded when I encountered Haskell the first time, I would say it’s definitely possible, but I think, there are some features in Haskell which can be used to break pure functional programming, and if those are not considered FP, then who knows. But I used Haskell the last time a few years ago, so my memory is definitely not clear.
Gilad Bracha talks about how they're not mutually exclusive concepts, and I mostly agree (OOP can have tailcall recursion and first order functions for example). But, the philosophy seems very different: functional programming is "standing above" the data, where you have visibility at all times, and do transformations on the data. OOP is much more about encapsulation, where you "send a message" to an object, and it does its own thing. So you could totally write OOP code where you provide some core data structures that you run operations on, but in practice encapsulation encourages hiding internal data.
Though on further thought, may be this isn't FP vs OOP, because C has a similar approach of "standing above", and C is the hallmark imperative language.
Scala has been that for decades. They are not opposing paradigms. (In fact, mutability has a few edge cases that doesn't play nicely with OOP to begin with)
I mean Scala kind of does both (and then some). I'm not sure I would call it an OOP language, but you can sure write the same gross Java enterprise bloatware in Scala too if you want.