However, most changes/refactorings I usually encounter are due to trivial problems that can be automated. And I'd love to have those tools for FP where a lot of changes are still just that: rename a function or a field in a data structure, extract a function, rename/move a module, update type signatures etc.
However, it looks like the stronger the static typing, the worse are the tools :) Not enough manpower to take care of them, perhaps?
As for Haskell, I think, it's a combination of manpower (so popularity, really) and the fact that the compiler wasn't developed with tooling in mind.
Thanks for conversation, stranger, and have a nice day!
This is interesting because another popular argument against Haskell is "Haskell's type checker can only check trivial properties that can be automated".
Either automating trivial things is valuable or it's not, and the anti-Haskell camp seems not to agree on which!
Java and Python are simply not languages that encourage (or even make possible) writing code that is easy under those changes. In Haskell you have immutability (if something is declared, that's its final value, so I can simply move it around), purity (code that is basically context independent), dumb data structures (no "enterprise boolean" with nontrivial internal state and ceremony to initialize), functional (no code attached to mutable data that may implicitly require data to be in special state), no nulls in flow control (that are invisible to a compiler, so yea good luck moving function around that expects no nulls), ergonomic creation of data/types (so you don't have strings/integers everywhere that are opaque to a compiler).
There is no contest, really. Maybe with some modern languages like Rust or TypeScript, but I haven't tried those.