OOP is not method notation. There's more to it (and arguably the notation part isn't required), and indeed you can't have both that and FP. OOP is the opposite of "referentially transparent".

Then it really depends what exactly you mean by OOP. Some people use the OOP features for modularity and structuring of the codebase, without any side effects/unmanaged mutation. Often they don't call it "OOP" then, but rather "a module system". But there isn't any theoretical distinction.

For example, I do _both_ Pure Functional Programming _and_ OOP (in the "module system" way) in Scala daily. And it works very nice IMHO, I encourage everybody to give it a try.

Use traits as interfaces for logical pieces of your business logic. Implement them in (case) classes which receive interfaces to other pieces of logic in their class constructor. Use a so called "Functional Effect System" like Cats Effect or ZIO to avoid raw side effects. And that's it, enjoy and profit.

It's impossible to get people to agree on what OOP is exactly, but almost everyone agrees that hiding/isolating mutable state (inside objects) is an essential part of it. Just google "what are objects in programming".

Totally agree that these paradigms are badly defined. See my other comment where I explain it more https://news.ycombinator.com/item?id=34217547

My point here was that all "OOP" languages (that I know) allow you, with all their "OOP feautres", to work with objects which actually don't contain any mutable state.

I'll let you be the judge whether it is still "OOP", but I know from experience that it's very practical for Software Engineering.

This is a pet peeve of mine, but referential transparency really doesn’t mean what FP people use it for. They use it as a fancy name for the same thing as pureness. Referential transparency is a syntactic thing and most languages without macros are referentially transparent — see this answer: https://stackoverflow.com/questions/210835/what-is-referenti...

When I talk about referential transparency in the context of FP, it's honestly of no consequence to me what the history of the term in philosophy is (mind you, I still find it interesting -- I didn't know this and it was nice learning about it -- but it doesn't significantly change my understanding of the term in the context of FP).

Technical terms can be overloaded, I don't think this is either surprising or problematic. Astrophysicists classify carbon as a metal; they're not wrong, it's just a peculiarity of the field that's almost always clear from context.

In the context of FP, the term "referential transparency" means that variables can be replaced with their definitions, and vice versa, without changing the semantics of the program. The term coincides with pureness, but IMO it emphasizes something different. "Pureness" is a negative definition, it the property of there not being any side effects. "Referential transparency" to me indicates what you can do with that purity: it allows you to reason algebraically about your program.

> most languages without macros are referentially transparent

I don't think so. In most languages, you cannot syntactically replace a variable with its definition and expect the semantics of your program to remain unchanged. For instance, in Python, given the following shared prefix:

    state = 0
    def f():
        nonlocal state
        state += 1
        return state
    
    x = f()

The programs

    x + x

and

    f() + f()

do not yield the same result, which is what you'd expect if referential transparency holds.