3 ms·
My take is that all this WET/DRY wisdom makes people think about abstractions in the wrong way -- it makes us debate them in term of when, rather than what and
by andrewingram 3y ago
My take is that all this WET/DRY wisdom makes people think about abstractions in the wrong way -- it makes us debate them in term of when, rather than what and why.
In my mind, the point of abstraction is to transform models such that we can build solutions in a way that is a better fit for the problems at hand. Reducing LOC and repetition is explicitly not the goal, sometimes a good abstraction may actually result in more lines of code (but more often it's less). So reducing LOC and repetition is commonly a happy byproduct, rather the reason we do it in the first place.
I see slightly more experienced programmers rebound from DRY to a point of having a pathological distaste for abstractions, and I find those codebases to be far more stressful to work in than ones which just happen to have a few bad abstractions.
- zelphirkalt 3y agoI agree with rather having good or correct abstractions than saving LOC. However, a bad abstraction can give readers/devs the wrong idea about what is behind it, how it works or how it can be used and when to rely on it. Unreliable abstractions are terrible. Leaky abstractions are also terrible. Both introduce a lot of mental load overhead.
- erik_seaberg 3y agoSome people choose “no abstraction” over “poor abstraction,” which I don’t understand. Working without any abstraction is the same as working with an infinitely leaky abstraction.
- andrewingram 3y agoYeah. A pervasive poor abstraction can be painful, but in my own experience most misguided abstractions tend to be somewhat superficial and easy to unwind. It does worry me to see so much rhetoric in the wider programming community encouraging people to avoid abstractions, because this is the kind of lesson that is easy to imprint on newcomers -- but I suspect the easiest way to get good at them, is to do them badly a few times.