[japhyr]

I haven't done large-scale refactoring work before. How does typing help with refactoring? Is it because you know exactly what's being passed into a function?

[orblivion]

Often enough, in Haskell, you can boldly make the primary change you want to make, fix all of the ensuing type errors in the rest of the code, and your refactored code will run as expected. The compiler will more or less tell you what you missed.

[incepted]

You missed "automated" in "automated refactorings". This is what I'm talking about.

Without types, IDE's can't perform automated refactorings: you need to supervise them and make sure the IDE didn't break code.

This can't happen with static types.

[montibbalt]

It makes manual refactoring easier too in the sense that you now have a tool that can tell you what you broke and how to fix it.

[ubernostrum]

Without types, IDE's can't perform automated refactorings

This is your obligatory reminder that the entire concept of automated refactoring was first developed in a dynamically-typed language.

[nickpsecurity]

Refactoring changes how various chunks of code interact with each other. Types usually provide security against a limited set of bad interactions. Abstract or compound types can provide security against even more bad interactions, among other things. So, having simple, compiler-checked mechanisms for enforcing good interactions helps when you make changes that can cause bad interactions between chunks of code.

[DougBTX]

Typing makes it easier to write a "find all references" function. Types distinguish whether a call to foo.bar() is calling the same bar as baz.bar(), which makes it easier to rename Foo's bar wherever it is used, but leave Baz's bar alone.

[luos]

It really helps when renaming methods for example. I am not sure how much it helps with extract method.

[JustSomeNobody]

Or that they're just used to their IDE doing all of it for them.