[NateDad]

The problem with refactoring dynamic languages is that it's very hard for static code checking to let you know when you've missed a spot.

For example, what functions take class Foo that should now expect class Bar? What functions called method Baz, that now should call Bat?

Static typing makes all of that trivial. You know with certainty, when you've hit all the right spots, because the code won't compile otherwise. Also, a lot of that refactoring can be done automatically through tooling. "Replace all calls of Foo.Baz() with Bar.Bat()". Trivial, done... and it's often impossible to do the same thing in dynamic languages. You have to rely on tests catching everything... and how many of those tests need to be updated now, too? What's testing your tests?

I love dynamic languages, don't get me wrong... but refactoring large code based is way easier to get correct in statically typed languages.

[vidarh]

If you need to touch a lot of places for refactoring on a regular basis, that should tell you you're not doing something optimally. If you write your tests so they are dependent on internal details of the other code, that's a warning sign too. Add to that, that at least in my experience, my Ruby code bases tends to end up far smaller than my old equivalent C code, and the problem tends to be a lot smaller than one might imagine.

Yes, you need testing discipline, but you need that with static languages too - if you think you're ok just because the compiler didn't complain.... Well, that's just a false sense of security.

[pointyhatuk]

My point entirely :)