Fundamentally I think OOP is either state or syntactic sugar. If your methods don't modify internal state then they're basically doing ad hoc type polymorphism

Fundamentally I think OOP is either state or syntactic sugar. If your methods don't modify internal state then they're basically doing ad hoc type polymorphism on their first argument (this is the way that virtual methods are implemented, by the way), which just makes the '.' syntactic sugar that at the same time limits composibility because it demands an inheritance hierarchy. Then it just comes down to whether or not you believe that mutable state is a good design choice. I don't. I think state is the root of all evil. For one, it makes my job as a PL researcher of 1) writing a formal analysis and 2) using the formal analysis to write a compiler, less attractive than blowing my brains out. Note that you can have objects without OOP. Python has objects. Python is not object-oriented. Same with O'Caml or Racket. I'm not arguing against using state. If you're programming a state machine, you may want to model it with state. That would be a pretty good choice. The problem is that OOP says everything is a state machine. Do you believe that or not? Either way, I'm putting my best efforts towards state-corralled languages.