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 justf(a, b)is a weak argument. What aref,a, andb? Those names, well chosen, will tell me more thanString,Integer, orBoolean. 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.
2 comments:
It's refreshing to see a "grown-up" commentary on type-declarations.
A commentary that deals with the obvious truth - each "feature" (eg type-declarations) has positive and negative impact on multiple design criteria, and we choose the compromise design that best suits our purpose rather than the best design according to a single criteria.
He's not saying adding enough negative numbers makes a positive -- although your phrasing sure made me click on the link out of mathematical curiosity! -- he's saying that even though:
min(compromise.quality < bestway.quality for bestway in applications) == True
it's also true that:
# even for various subsets of 'applications' less than the entire collection
compromise.cost < sum(bestway.cost for bestway in applications)
There are no negative numbers involved. :)
Anyway, he's given a pretty decent summation of my interest in type declarations, even though he doesn't mention adaptation. Syntactical support for adaptation would actually be a use case where a declaration syntax would be as good or better than the current alternative.
Post a Comment