4 ms·

I somewhat disagree. This will be true for pretty much any non-trivial code project. I'd love to see a language where I didn't need tools to understand what's h

• codygman 6y ago
  > Do you really never need to see what a passed-in function actually does in your FP code? I'm hesitant to say always, but I can say: - in imperative code I never feel comfortable without inspecting the passed in function - in pure functional code, I rarely feel uncomfortable taking a pure function at it's word
• Weebs 6y ago
  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