This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-23
Channels
- # babashka (18)
- # babashka-sci-dev (42)
- # beginners (84)
- # calva (11)
- # cider (5)
- # clj-kondo (11)
- # cljdoc (70)
- # cljs-dev (34)
- # clojure-europe (1)
- # clojurescript (3)
- # conjure (1)
- # core-async (29)
- # data-oriented-programming (10)
- # emacs (13)
- # fulcro (8)
- # gratitude (2)
- # honeysql (1)
- # introduce-yourself (4)
- # kaocha (10)
- # missionary (8)
- # nrepl (4)
- # off-topic (27)
- # portal (32)
- # releases (11)
- # tools-deps (11)
- # xtdb (19)
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"?
This is an example: https://github.com/teodorlu/reflect.teod.eu/blob/master/src/teod/reflect/filewriter.clj
I added so much flexibility that I don't really know how to work with it. Many moving parts.
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)
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
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
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})
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
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.