Which way you really want a refactor to go can depend on the presence of the type system. As well the reliability of refactoring doesn't.

For example consider the thing you constantly see in Java where you construct an object then assign each property through a method. The type system will catch it if the property is not passed correctly.

In a dynamic language like JavaScript the same is better done with an inline object. The reason being that the type system won't catch it if there is a mistake, and so you want to go for the easiest way to write it. On the theory that less code is less maintenance.

However now it is hard to rename a property and be sure that your refactor is correct. Because where does a property come from? It could come from anywhere - over the network, from an API call, the name of a database field - it is easy to miss it.

Which means that not only should the refactor go in a different direction, but how safe you feel in doing refactors will also go in a different direction!

In a typed language, an IDE can make breathtakingly large refactorings that are 100% correct.

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.

Types help eliminate an entire class of unit tests one would need to write before refactoring. Things like newtype also allow enforcing certain constraints while refactoring. So yes, while the end goal is the same, the process is simplified.

I’m not against types. In fact I mostly prefer typed languages.

I’m just stating that there is nothing fundamental about code-refactoring which ties it exclusively to the domain of typed programming-languages, something I consider fairly self-evident.

I mean obviously one can refactor terrible code in any language to help improve its structure right?

That this remark would cause such sub-thread defending types in general (I never said they didn’t have value) has me honestly quite surprised.