I agree that dynamic typing and reflection make refactoring more difficult. IDE assistance features like code completion also depend upon type info, and likewise become harder in its absence. Static typing is all about discarding power and flexibilty to gain stability and certainty. But in the real world, types change, and programs change. Static typing merely says that if you agree to never speak of such things in your programs, you gain some benefits. But we MUST speak of these things, and so, for example, Java adds reflective mechanisms on top of the language that defeat the guarantees of the type system. In the presence of reflection, many refactorings become unsound or undecideable.

Dynamic languages like Lisp or Ruby are popular in large part because they are not straightjacketed by types, and can freely do metaprogramming tricks without laborious reflection and code generation as in Java. But this dynamism means that it is harder to say what code can and can’t do just by looking at it.

We need to escape this barren dichotomy. Erik Meijer proposes “Static typing where possible, dynamic typing when needed”. http://research.microsoft.com/~emeijer/Papers/RDL04Meijer.pdf. My own plans for Subtext are to add a form of “static” typing in predicates that attach to variables, performing runtime checks, but also being sufficiently declarative to allow a form of type inference.