Fork me on GitHub
#off-topic
<
2020-08-08
>
Adam Helins14:08:22

Is there a name for the following psychological phenomenon: feeling the strong urge to abstract away 2 functions having very similar-looking implementations but differing sufficiently so that abstracting them is difficult/impossible/counterproductive? Out of curiosity

Adam Helins08:08:13

I am a psychologist by training, have asked other psychologists, and I can't manage to find a suitable existing name!

jaide21:08:36

Oof that used to drive my crazy when former co-workers would do that and two unrelated systems that happen to have a few behaviors in common are now forever coupled. I would love to know a psychological term to point to. Though part of me wonders if it’s just an inexperience thing where DRY is treated as the ultimate rule rather than a guideline? I feel like once you stay with a project long enough, you eventually get bit by making things over-dry and thus learn the natural limits of that practice. On the other hand, could it be considered like a mild OCD behavior?

Drew Verlee18:08:44

I wouldn't say there is a single word to describe that. Category theory is the study of how things relate. You could use that language to be precise the difference in a way others who know it understand. There are dozens of us. I jest, I don't know category theory.

noisesmith18:08:08

my take is that a good heuristic for an abstraction is repetition

noisesmith18:08:24

repetitive code is often a sign of a higher level abstraction you could use, but if the thing the repetition has in common is incidental (eg. tied to implementation details of an external service, or a choice of algorithm that isn't final), the thing that looks like "abstraction" will often be the opposite - coupling of a contingent choice into the basis of a design

noisesmith18:08:32

often, if you can't come up with a good name for the repeated thing, or the name has something to do with unimportant implementation details and not the domain of the code, reducing that repetition is a decrease of abstraction

noisesmith18:08:35

In clojure we can cheat (eg. abstracting certain data usage patterns) because certain data structures are effectively essential and non-contingent because they have so much language support. This sort of thing works great in the fine grained detail of our code, but above that into higher levels it's often a problem to follow that same style, because the things you are complecting the code with are no longer guarantees

noisesmith18:08:34

often the bad abstractions are a developer's failure to "switch gears" between the refactors that are helpful inside one function and the ones that make sense across a namespace or between libraries

ksd19:08:48

“This sort of thing works great in the fine grained detail of our code, but above that into higher levels it’s often a problem to follow that same style, because the things you are complecting the code with are no longer guarantees” Could you elaborate and give an example? I am not sure if I understand