The impossibility of refactoring in a weakly-typed scripting language

I need to change a bunch of functions in a bunch of classes to take a "user" object as opposed to a "user_id" number.

I am using a scripting language. How am i going to do this? I am going to do it the best I can, then compile, but the compiler is not going to find any problem as they are the same "type" i.e. they are both values.

Then i'm going to get lots of runtime errors. I'll correct them until they all go away. Then there will be no known runtime errors. Which is better than known runtime errors. But both more difficult and much less satisfactory than a simple compile in a language like Java or C++ which would find all occurances of such errors.

Thankfully I have lots of unit test scripts which will help in my unnecessary debugging process. A lot of them I just wrote to test simple things like "do getters work?". In a compiled language many of those tests would be unnecessary as the only errors that could occur, the compiler would pick up.

So scripting languages have caused me more effort:

  1. To do and test this change
  2. To write and run and maintain unnecessary unit test scripts
  3. To write this blog post (which wouldn't have been necessary had points 1+2 not been necessary).

But it doesn't even stop there. Because refactoring is so difficult, it means people don't do it. This means that code over a certain trivial age in scripting languages is worse factored than that in a language with better tooling. That's the real cost.

This article is © Adrian Smith.
It was originally published on 7 Mar 2007
More on: Language Design