3 ms·
One point about abstractions that you might want to make in a future article is that developers tend to discount the cost of all abstractions that they have int
by btilly 4y ago
One point about abstractions that you might want to make in a future article is that developers tend to discount the cost of all abstractions that they have internalized. Therefore when they get to a new environment, they immediately try to recreate and incorporate the abstractions that they used previously.
However these abstractions are not free. They are not free for performance. They are not free for debugging. And they are especially not free for any future developer who is not familiar with them.
The joke I grew up with was, "Andy giveth, and Bill taketh away." It is no longer Intel under Andrew Grove who gives us better performance. It is no longer Microsoft under Bill Gates who gives us slower software. But the basic phenomena is still true. Hardware improves over time. But developers happily introduce abstractions with no awareness of the associated costs.
- throwaway2037 4y agoYou wrote: <<They are not free for debugging.>> Thank you. Finally, someone acknowledges this important point! I have literally been told that adding extra local variables was "increasing stack size; must be slower". But what about debugging? And, yes, there is a balance to be had between maintenance and speed. Example: Breaking down a critical path section of code into a bunch of tiny non-inline functions may slow down the code unacceptably. In other cases, it may make the code much easier to read, maintain and debug... so the trade-off is acceptable.
- dandelany 4y agoHard agree. On the flipside, devs also tend to overestimate the cost of already-implemented abstractions that they haven’t yet internalized, leading to complaints and lengthy refactors when they could have just spent the time to learn the abstraction…