If you need an external tool to understand code it’s an indication that something is wrong.

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 happening, but that's impossible currently.

Do you really never need to see what a passed-in function actually does in your FP code? Never need to see what type an argument is in our fancy Haskell or Hindley-Milner-typed language?

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

> 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

If one refuses to adopt modern tooling it’s an indication that something is wrong.

Is that? If you don't write all your code with `cat`, is that an indication that something is wrong as well?