I've been ignoring a recent thread or two on the Ruby list discussing the addition of some sort of type checking. I did pop in to one post today that seemed to sum up my position before I even knew what my position was:
you see we have a problem here. it doesn't matter what methods are implemented, because ’>’ for a String and ’>’ for a Numeric don't DO the same KIND OF thing. the operators are overloaded. so respond_to? isn't enough. we end up having to think about what will be passed to those responding methods as well -- we end up having to ask not only, can you handle the responsibilities? but can you handle the arguments?
My reply:
So we'd like the code we write to tell us when we've screwed up, but a typing system is basically not smart enough, because type alone does not determine functionality.
I guess we're back to unit testing.
Or am I over-simplifying?
Am I?
Since I'm on the topic, I just ran across this point which I thought quite precise:
Strong typing allows errors to be detected at compile-time, so the cost of run-time checks is avoided. However, the price to be paid for this efficiency is restrictions on how information can be used: this results in more code and less flexible programs.
And in my experience, the gain in flexibility in a language like Ruby, combined with unit testing, which, in my opinion, is the better way to ensure things are working anyway, makes the price to pay for strong typing too expensive for my pocketbook.
tags: ComputersAndTechnology
