Oliver Steele seems to conclude that adding enough negative numbers may have a positive result. I'm not sure I get all the way to the same conclusion, but the argument is unique.
Update: OK, I definitely do not get to the same conclusion. Saying a type declaration "does a poor job of each scenario, and that means it does a good job of doing them all at once" is a leap I cannot make.
I don't see Oliver addressing the cost side of the equation sufficiently for his benefit side to come out greater. I think the costs can be overcome with creative work, but I'm not sure that's where I'd want my most creative thinkers working. Making type declarations optional alleviates costs, but why bother? I am just one who does not see the benefits.
Since Oliver already points out weaknesses in any one of the scenarios, there is no point attacking them individually. I cannot argue against the whole because I don't see a complete equation that can be analyzed. But I will point out some glaring problems he's passed over.
- Documentation Providing
f(a: String, b: Integer): Booleanrather than just
f(a, b)is a weak argument. What are
b? Those names, well chosen, will tell me more than
Boolean. Moreover using Smalltalk's keyword syntax you have even more expressiveness than this Pascal style.
- Early error detection Test-driven development eliminates the gap between coding and testing. There is no "earlier" time for detecting type errors.
- Discouraged from writing tests If your language is so bad that programmers are discouraged from writing tests, my friend, well, type declarations are not going to make up the difference.
I have another post to make responding to PJE, which I have learned is *not* about type declarations per se. Coming soon.