This is a funny subthread considering the first useful refactoring tools were for dynamic languages[0], not static ones. Static types might have some advantages for a refactoring tool, but dynamic languages have their advantages too that might make a refactoring tool easier to create.[1]

Can refactoring tools miss something? Sure, but this holds true for various static languages too. Don't sell the nonsense of 100%. Find me a Java IDE that won't miss reflection calls. (Personally I can point to a tool for Java that moves the bar above 0, but it also isn't 100%.)

Just because you're used to shitty dynamic languages isn't a statement about dynamic languages in general or the possible tooling, anymore than being used to shitty static languages is a statement about static languages in general or the possible tooling. I also see someone conflating "dynamic" with "untyped"/"non-typed" -- there are very few untyped languages, let alone in wide use, "dynamic" doesn't mean the same thing.

I'm looking forward to the JS version of the book just for recommendation purposes because I hope it will put a rest to so many of these threads about refactoring in the absence of a static type system being somehow way harder or impossible.

Ultimately I think the discomfort is from fear, certain programmers practice fear-driven development. "What if the tool (or me, if I'm taking 5 mins instead of 5 seconds to do it) misses something?" It's the same fear with people who can't imagine refactoring without unit tests, but who need to refactor legacy code to get it under test. You can do these things, they're not particularly difficult, but if you're suffering from fear, I'm not going to convince you. Maybe a book + examples would though.

[0] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91....

[1] http://wiki.c2.com/?RefactoringBrowser

Ralph Johnson: "We originally thought that the lack of static type-checking would make it hard to build a refactoring browser for Smalltalk. Lack of type information is a disadvantage, but the advantages of Smalltalk made it a lot easier to make a refactoring browser for Smalltalk than it would have have been for C++ or Java."

That’s obviously true, but you seem to be conflating refactored code with tooling support for refactoring.

Done by a tool or not, the refactoring in principle remains the same. The tool merely automates the transformations which defines the refactoring.

And in that sense types isn’t really essential to refactoring at all.

Types make it much, much easier to write useful refactoring tools, and to verify that the tools did the right thing.

In theory it might be non-essential, but in practice it might mean that refactorings might be unfeasable or too costly in non-typed codebases.

The more I think about it, the less it makes sense to bother about refactoring when you did not bother about type level guarantees in the first place.

I'm not conflating anything. Just stating a fact.

Most common refactoring can be done in any language. If you have types, that really just means the compiler is testing many of your assertions.