But whenever I’ve tried to make a custom type in Ruby, and introduce it into code that was already using a primitive, I’ve missed places, even when I had unit tests. Generally it’s because I miss some of the glue. I test classes individually, and when the interface of one changes, I forget to update the tests of all its playmates to show the new contract (and the tests don’t tell me about the problem, because they’re testing each class in isolation). Usually it’s not until I run through a particular code path, much later, that I find that I missed something.

I’ll be the first to admit that I’m not that skilled yet at writing unit tests in a dynamic language (and feel free to blog about how to do this sort of thing effectively, or point me to some articles — I’d love to learn how to do it). But given where I am now, I prefer having a statically-typed compiler to lean on for changes like this. Granted that the compiler gets in the way for a lot of other things, but this specific thing is the very thing statically-typed compilers are good at.

I will be the first person to say that most systems do not have enough types. Programmers today still rely too heavily on primitive types when more robust, functional objects could accomplish the task much better. To that end, I agree with the sentiment you’ve expressed.

But, that said. The idea that we should do this sort of thing because then we can let the compiler catch our mistakes just rubs me the wrong way.

There is not one kind of error that a compiler will catch that a unit test would not. Furthermore, there are entire classes of errors that unit tests will catch that a compiler can’t possibly detect. This is why statically typed languages are at a disadvantage when it comes to speed of development. They add cumbersome requirements to the code without adding truly discernable advantages in the long run.

Just keep in mind how often you find yourself saying "Man, I wish I had this feature from Ruby in Delphi," or "Dude, the syntax for Ruby-style blocks in C# is clunky." I know how often I say it, and how often I hear it.

Just remember, a vast majority of "new" programming ideas that are coming out for statically typed languages today have been in dynamic languages like Smalltalk and Lisp for decades. And all the rest are easily implemented. The converse isn’t always true.