4 ms·
I was also just thinking this… but really only realized it reading the grand-post. Probably the general rule is simply, “you get more bugs when expectations do
by tyleo 3y ago
I was also just thinking this… but really only realized it reading the grand-post.
Probably the general rule is simply, “you get more bugs when expectations don’t match reality”.
Example:
1. (null) This value can’t be null
2. (article) This value won’t be converted into a date
3. (misc) This API can be called frequently
- lmm 3y ago> Probably the general rule is simply, “you get more bugs when expectations don’t match reality”. That's too vague to be useful. You might as well say "you get bugs when you write wrong code". Whereas framing it as a lack of type safety points towards an actionable solution.
- eyelidlessness 3y agoI think this is too strong a take. The general rule, as stated, can be useful as a way to think about systems, interfaces, architecture, etc in broad strokes as a vector for expectations which might fall victim to this pitfall. Being general, it isn’t prescriptive about the solution… but then, type safety isn’t always (and isn’t the only) solution. It’s a way to think about problems where you explicitly scrutinize the expectations they promote and their corresponding realities. You might arrive at type safety as a measure to align those, but you might also consider a variety of other concerns in the same thought process. It’s only unuseful if the problem you’re applying it to is itself vague, or if you’re unprepared to do the thinking involved in understanding a more specific problem and what expectations you’re addressing in solving it.