> where's the code that messes with this data That just sounds like a code organization problem not an argument in favour of OOP. > but also not the case in m

> where's the code that messes with this data That just sounds like a code organization problem not an argument in favour of OOP. > but also not the case in most OO languages The fact that a lot of "OO" languages don't enforce this doesn't change the fact that the general sentiment around object oriented programming as I see it taught and as I see new programmers approach it is that "everything has to be an object." The problem with OOP is not just OOP languages but also OOP programmers who you have to deal with on a regular basis and have to explain that "this could just be a function, why do I need to instantiate a class to do this basic task?" > Huh? This one is made up. Once again, this doesn't matter in light of how people ACTUALLY write code in those languages and what actually is the status quo. > this is a feature not a bug Not sure I know enough about javascript to understand what you mean here. Hiding state inside things is fine when it's done correctly, more often than not in reality when people write object oriented code it is done poorly. I certainly haven't had the same troubles understanding what happens to state when reading someone else's pure functional code vs when I've had to read someone else's object oriented code.