I'd argue you're right, but when you're programming in something like Haskell that guarantees certain constraints are met just by glancing at declarations, thes

I'd argue you're right, but when you're programming in something like Haskell that guarantees certain constraints are met just by glancing at declarations, these tools become less essential. In FP, I tend to look at implementations to understand what they'll produce In OO, I do this, but I also need to know _how_ since they might be changing the current context I'm working in. It's not enough to know that X method produces Y, I also need to remember that calling X implicitly modifies Z when I'm referencing Z In an FP environment X can't modify Z outside of his context, so I don't have to care about how he produces Y. The cost of this is that someone needs to own Z and functions need to additionally return the new Z, but I think that explicit hierarchy helps in guiding towards a more understandable architecture