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

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.9246&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.... [1] http://wiki.c2.com/?RefactoringBrowser 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."