This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-08
Channels
- # announcements (1)
- # babashka (18)
- # beginners (32)
- # calva (3)
- # chlorine-clover (4)
- # cider (14)
- # clj-commons (24)
- # clj-kondo (1)
- # clojure (34)
- # clojure-europe (4)
- # clojure-filipino (1)
- # clojure-uk (4)
- # clojuredesign-podcast (2)
- # clojurescript (6)
- # conjure (3)
- # core-async (2)
- # datahike (1)
- # datomic (3)
- # emacs (3)
- # esprit (20)
- # fulcro (4)
- # graalvm (11)
- # helix (13)
- # honeysql (4)
- # jobs (1)
- # lumo (1)
- # observability (4)
- # off-topic (11)
- # other-lisps (6)
- # pathom (6)
- # re-frame (13)
- # reagent (1)
- # reitit (1)
- # shadow-cljs (26)
- # web-security (2)
- # xtdb (10)
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
I am a psychologist by training, have asked other psychologists, and I can't manage to find a suitable existing name!
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?
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.
my take is that a good heuristic for an abstraction is repetition
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
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
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
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
“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