Based on the OP’s statements about DRY and issues with abstractions, it sounds like most of these problems are resolved by using an ecosystem that has good abstractions. In my experience, the abstractions that don’t leak and actually enable you to write better, shorter, cleaner code faster tend to be “math-y”. For example, it’s crazy how much time and bug exposure you can eliminate with straightforward abstractions like applicative functors or generic folds. However, for these to be useful and scale well, they have to follow certain well-defined laws, or else you end up with the java ecosystem where things randomly throw UnsupportedOperationExceptions instead of actually implementing the full abstraction.
A while ago I had the thought that the best abstractions are things we forget are abstractions at all. They just turn into a new noun/verb and we forget they are an abstract thing at all… Things like logic gates, function calls, etc.
This only works when said “good abstractions” are expressible in a precise, non-leaky way. For most of us, this is an unaffordable luxury.
Hmm. It does read rather like one of those generic “X is Bad because I am Bad at X” articles.
If I had a leak in my tire…. I’d fixed it.
The reason why the likes of Fowler and co say small functions is you can only find a good abstraction in a small function.
Make it too large…. and yup, your abstractions are going to leak.
Already posted here; didn’t get caught because she changed her medium handle. Maybe we should also check the last part of the path or the title when checking for duplicates?
I think this is an edge-case, this is the first time I see that happening.