>Conceptually, procedural languages like C are doing that too for files, they’re just writing object.Verb as object_verb(Handle instance). The main problem wit

>Conceptually, procedural languages like C are doing that too for files, they’re just writing object.Verb as object_verb(Handle instance). The main problem with OOP is the promotion of mute-able state, this is what ties everything together and makes everything less modular. Though semantically equivalent object_verb(object) is actually better than object.verb when you consider mutations and side effects. Seriously I want you to consider this: Two classes A and B. class A: def __init__(self, x): self.x = x heavy_computation() def addOne(self): self.x += 1 class B: def __init__(self, x): self.x = x def addTwo(self): self.x += 2 Let's say I want to write an addOne method for B. How do I reuse the code for addOne in A inside of B? 1. Inheritance. Make a base class have A and B inherit from it. 2. Duplicate code by writing a duplicate method. 3. Dependency injection, modify B so that it takes A and Does some crazy stuff: class B: def __init__(self, x, a): self.a = a(x) self.x = x def addOne(self): self.a.addOne() self.x = self.a.x def addTwo(self): self.x += 2 self.a.x = self.x All three options are bad for various reasons. There is no option where I can just add a method to B without modifying any other part of the program or duplicating code. AddOne is not reuse-able because it's tied to mutable state and the constructor and all the methods that share that state. This happens regardless of whether or not it's A.addOne() or addOne(A). The only universe where addOne can be reused is if it started off as a stateless function (addOneFunc) def addOneFunc(x): return x + 1 class B: ... def addOne(self): self.x = addOneFunc(self.x) By making addOne a functional concept I am able to impliment B.addOne without modifying anything else and reusing code to maximum effect. You cannot do this easily with OOP and this is why OOP is bad. If I want to deal with mutable state, it's actually not technically FP anymore. Inevitably I will have to and that's why many FP paradigms segregate IO with FRP patterns or the IO monad. Even still straight up procedural programming with mutability is still better than OOP because addOneFunc: def addOneFunc(int& x): x += 1 is more reusable than addOne: class Jungle: def __init__(self, x, gorilla, banana): self.x = x heavy_computation() self.jungle = create_jungle(create_gorilla(banana)) def addOne(self): self.x += 1 “… Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. “ —Joe Armstrong Many people will say don't design your programs this way. Well nobody has the foresight to know exactly how their primitives will compose for the design they have now and in the future. With OOP you will inevitably design your program into a wall because when it comes time to reconfigure the bricks in the wall you realize that OOP has super glued everything together. What happens IRL is that people eventually hit more complex versions of the example problem I gave you above.