This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-29
Channels
- # aleph (5)
- # announcements (2)
- # bangalore-clj (2)
- # beginners (52)
- # cider (10)
- # cljsrn (1)
- # clojure (160)
- # clojure-dev (24)
- # clojure-europe (3)
- # clojure-france (1)
- # clojure-india (1)
- # clojure-italy (3)
- # clojure-nl (6)
- # clojure-spec (13)
- # clojure-uk (51)
- # clojurescript (45)
- # code-reviews (1)
- # core-async (41)
- # cursive (41)
- # datomic (17)
- # emacs (37)
- # fulcro (42)
- # graphql (7)
- # joker (4)
- # music (1)
- # nrepl (2)
- # off-topic (21)
- # pathom (19)
- # pedestal (12)
- # re-frame (48)
- # reitit (6)
- # rewrite-clj (8)
- # shadow-cljs (41)
- # specter (6)
- # sql (21)
- # tools-deps (8)
- # vim (7)
- # xtdb (27)
brilliant!
I wonder how language with static type system inspired by clojure spec (alpha2) will look like... instead of class as a unit of data shape definition it will be "attribute" or something, and what is class in languages like java will be created more dynamically as schemas, with effortless conversion between such "classes"...
I have toyed with the idea of elevating the relations between entities in your system from code to a more conceptual representation mapped back to Clojure (somewhat similar to the idea of UML -> Java code mapping, just with less pain by using more modular solutions, like Datascript for storing facts)
if you remember Rich’s talk about 10x harder problems of SE, it would be nice to see some advancements in Domain-driven design in the Clojure space, since that part is the easiest to get wrong/keep maintainable/monitorable
the need to concretize every aggregation in langs like Java is exactly the reason Java is so cumbersome for information processing
Anyone has interesting experiences regarding dependency rejection? https://blog.ploeh.dk/2017/02/02/dependency-rejection/
He links to https://blog.jessitron.com/2015/06/ultratestable-coding-style.html which is a easily graspable example of the pattern (with a Clojure implementation)
Intuitively I would say that a no-dependencies architecture might be feasible for a CLI tool that does a single discrete task, but in a real-world distributed system (w/ microservices, multiple data stores and stuff) things aren't so linear.
Currently I do use/advocate DI with clojure.core/defprotocol and Sierra's Component pattern. Doing otherwise seems possible but also a large/fragile effort, especially in a dynamic language like Clojure.
https://github.com/tolitius/mount might be a good alternative to Component framework if you want to avoid DI/protocols everywhere 😃
@ Andre, I don't have a practical problem with those 🙂
My question is more about how you architect your application - especially towards side-effects.
e.g. with the Component pattern, whereas one would just clojure.core/spit, one could place a Writer protocol/component instead. So that code that spits becomes testable, since the side-effect can now be replaced with a mock.
...that's pretty OO-ey, but it works for me atm.
The README of the lib might explain some of those questions. Even if you don't pretend to use, it's a really good reading.
my opinionated view on dependency rejection : • DI and state management are orthogonal concerns and should be addressed separately • the DI is just argument passing meme is FP smug in all its glory and misses the point of DI, which is to reify the system topology
What should DI look like in clojure then? Because I think right now I would describe it as argument passing?
IMO plumatic graph https://github.com/plumatic/plumbing captures the essence of DI, although it's not really described as such. I also made a minimalistic tool in the same vein https://github.com/leonoel/injure/ Argument passing works with toy examples, but in my experience doesn't really scale to real-world applications, you quickly end up with a lot of boilerplate code.
it sounds similar to what Rich has been saying about simplicity in many ways :thinking_face: Instead of building up a hierarchy of x calling y, you pass things around, make them shallower and compose them at a higher level. x doesn't need knowledge of y. It's essentially the same code though, just broken up into different places. I expect the result would be more repl friendly.