|
|
|
|
|
by wrs
319 days ago
|
|
It’s not really an abstraction budget, it’s an “unfamiliar abstraction” budget. You only pay cognitive load for an abstraction when you haven’t yet internalized the abstraction. Otherwise progress would have become impossible long ago. There’s a huge pile of abstractions in that codebase that you have internalized to the point of invisibility — machine instructions, virtual memory, ASCII, sequential execution, named variables, garbage collection, network streams…literally thousands of these abstractions had to be invented and become second nature to you so these other abstractions that currently aren’t as familiar could be based on them. A good abstraction gives a return on investment of effort internalizing it. There’s no limit on how many good abstractions you should have. |
|
Like way more than the rule of 3. Even a dozen uses (if it’s only going to be local to just that particular project) is not enough for me.
Edit: and maybe this just says more about the kinda of languages I use at work, but I feel the conventional, widely understood, idiomatic way to do lots of things is often heavy on boilerplate. If these languages were rewritten from the ground up I imagine with hindsight the core languages and standard libraries would look pretty different and be more ergonomic.