Fork me on GitHub
#data-oriented-programming
<
2022-04-23
>
teodorlu09:04:58

Hey! I have a bad habit when writing Clojure code of adding too much flexibility too early / trying to data-orient all the things. This can lead to my Go code being more legible than my Clojure code. Bad case of premature abstraction/indirection. Anyone know if this has been commented on in a DOP context? Curious if others have the same problem. And if you use DOP from the start, or if you "refractor to DOP when required"?

teodorlu09:04:15

I added so much flexibility that I don't really know how to work with it. Many moving parts.

teodorlu09:04:14

It's just a system for writing html. But I want to work with EDN/hiccup, and also org-mode/pandoc, and also have some dynamism (clojure code)

teodorlu09:04:37

Right now it's not complete. Currently (last time I had time/motivation) working on the unit tests for the pandoc namespace, which was a bit harder than I expected. https://github.com/teodorlu/reflect.teod.eu/blob/master/test/teod/reflect/pandoc_test.clj

wilkerlucio14:04:33

I personally try to avoid indirections at start, first need to make sure all required implementations are available (using your example, a writer impl fn for hiccup html), them, if the code only needs one, just call it directly, I think adding indirections (like multi-methods) should be a later decision if you see that you need external extensibility

👍 1
wilkerlucio14:04:45

I personally had many times just wrote a map to wrap multiple implementations, when I didn't see a need for extension, would be something like:

(defn hiccup-html-output [x] ...)
(defn hiccup-markdown-output [x] ...)

(def encoders
  {:hiccup-html hiccup-html-output
   :hiccup-md hiccup-markdown-output})

👍 1
wilkerlucio14:04:42

I think its a problem to not have the pure/simple version of just a function (eg: have the implementation tied to a multimethod only), because it makes harder to test, and the reader ends up complecting the implementation detail with the dispatch mechanism

👍 1
Xarlyle014:04:45

I'm not sure how much DOP specifies when to use a tool like a multimethod. It definitely seems in this case that these can just be separate functions. I would only turn to multimethods when it is somewhat obvious that a user of a library might want to extend its functionality, but it is unclear how a user would want to do so.

👍 1
teodorlu13:04:57

Good points - thanks! Yeah, I was feeling like "hey, it's possible to use multimethods here!", without really having a good reason why I'd want to do that. Using multimethods to provide extensibility for a user of a library (like integrant does) makes sense.