OOP is about information hiding and providing well defined state transitions. objects are used to hold a state and to act as gateway for valid transitions. mo

OOP is about information hiding and providing well defined state transitions. objects are used to hold a state and to act as gateway for valid transitions. most complaints I see come from people using OO programming languages badly, leaking abstractions all over the place and making it so you have to mentally take care of the state of everything instead of trusting your objects to take care of themselves, and thus you get the worst of both world: rigidity coupled with complexity I need information hiding because my brain is only so big, so I cannot possibly have in mind the whole application state and all it's permutation at all time while programming. functional languages work similarly in a sense: you avoid thinking about state transitions because the only things you have to take care of is each function input and output in a broader sense, programming becomes way way simpler if you think of your functions as having 4 well defined input output: the inputs, the return values, data from a persistent store and a state. And with experience you start noticing that it is much much more simple and productive if in any of your method at a given time you only reduce the 4 io ports in 2: on one side you have functional languages, only ever working with inputs and returns, on the other you have OO languages, which focus so much on the input, state and state, return couples. mastering the ability of using both styles where appropriate is the key here. but people get dragged into name specific too much, forgetting that these pattern emerged from coding and not the other way around.