3 ms·
Thank you, I had the same fuzzy thought in the back of my mind while reading this but couldn’t quite put it into words. The idea of depending on developers to u
by spaceywilly 4y ago
Thank you, I had the same fuzzy thought in the back of my mind while reading this but couldn’t quite put it into words. The idea of depending on developers to understand “usFoo” means this is an unsafe string and “sFoo” means this is a safe string seems error prone. Those rely on the developer knowing what “us” and “s” represent.
A much better idea would be to give that information to the compiler, so the developer can get a useful error if they try to do something unsafe. We should try to turn these onto compiler errors as much as possible so if a developer does something bad, it wont even compile. This seems like a much more fool proof way to accomplish what the author is trying to do.
- deleted 4y ago[deleted]
- BryantD 4y ago100% true. It’s a sign of evolving understanding of software engineering — in 2005, it was still common to believe that the best way to prevent errors was to help fallible human beings learn to detect them better. Now, well, it’s still common but we’re overall getting smarter about letting computers protect us from ourselves. (And the kind of technique described here still matters because you should understand why the guardrails are where they are.)