The way I like to use OO (usually not real OO, but rather class-based languages) is to minimize its mutable state. Often mutability is merely a lack of using builder patterns. Some state can be useful as long as it's easy and makes sense to globally reset or control. It's like writing a process as a construction of monads before any data is passed into it. Similarly a tree of processing objects can be assembled before running it on the input.
I've probably written more Java than any other programming language during my career, and I've seen both good and bad ways of writing Java.
Bad java heavily uses lots of inheritance, seems to think little about minimizing exposed state, and (unrelated to this discussion) uses lots techniques I like to call 'hidden coupling' (where there are dependencies, but you can't see them through code, as there is runtime magic hooking things up).
Good java almost never uses inheritance (instead composes shared pieces to create variation on a theme), prevents mutability wherever possible, and makes any coupling explicit for all to see.
Good java still has classes and objects, but starts to look pretty 'functional'.
I begrudgingly have had to enter the world of Spring Boot over the last couple years, and this drives me nuts. Every damn thing needs getters and setters so that the ten thousand magic Spring annotations can mutate things all over the place. If the business logic is complex, I try to make immutable domain models separate from the models that have to interact with Spring, but that can require a lot of boilerplate.
I had a different read of that point. More along the lines of “don’t throw the baby out with the bath water” (might have butchered that saying?).
I’m also more in the FP camp - even wrote a book on the topic of FP. But I also acknowledge OO is not inherently a bad choice for a project, and many languages nowadays do exist along a spectrum of OO and FP rather than being strictly one of the other.
To me a benefit for OO might be the ubiquity - you can generally assume people will understand an OO codebase if they have done a few years of coding. With more strict FP that is just not a given - even if people took a Haskell course in Uni a decade ago :).
> OO is not evil, but it also shouldn't be your default solution to everything.
With Smalltalk and Objective-C both being effectively dead at this point, that really only leaves Ruby (and arguably Erlang) as the only languages that are able to express OO. And neither of those languages are terribly popular either. Chances are it won't be your default solution, even if you want it to be.
Curious about your case for this. I don't know a lot about Erlang other than "it's what Elixir is based on" or whatever technical jargon is more accurate. I thought it was functional.
I was mostly riffing on the time Joe Armstrong, creator of Erlang, said that Erlang might be the only object-oriented language in existence. Although he's not exactly wrong, is he?
> I thought it was functional.
I think that is reasonable. Objects, describing encapsulation of data, are what define functional. Without encapsulation, you merely have procedural. Of course, that still does not imply the objects are oriented...
For that you need message passing. But Erlang has message passing too! So there is a good case to be made that is object-oriented.
Patrick Naughton came from the Smalltalk world, so Java is definitely inspired by Smalltalk, but he didn't bring along the oriented bits. Its object model is a lot closer to C++'s. To have objects does not imply orientation.
OO is not evil, but it also shouldn't be your default solution to everything.
Also, who is this person? I immediately distrust someone who calls themselves 'a pretty cool guy'. That's for the rest of us to decide.