> In any nontrivial codebase, this inevitably leads to bugs when, for example, a string representing a user ID gets used as an account ID Inevitably is a stron

> In any nontrivial codebase, this inevitably leads to bugs when, for example, a string representing a user ID gets used as an account ID Inevitably is a strong word. I can't recall the last time I've seen such bug in the wild. > or when a critical function accepts three integer arguments and someone mixes up the correct order when calling it. Positional arguments suck and we should rely on named/keyword arguments? I understand the line of reasoning here, but the examples are bad. Those aren't good reasons to introduce new types. If you follow this advice, you'll end up with an insufferable codebase where 80% LoC is type casting. Types are like database schemas. You should spend a lot of time thinking about semantics, not simply introduce new types because you want to avoid (hypothetical) programmer errors. "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures."