Fork me on GitHub

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"...


Yeah, got me thinking


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

Alex Miller (Clojure team)13:08:22

the need to concretize every aggregation in langs like Java is exactly the reason Java is so cumbersome for information processing

💯 4

Anyone has interesting experiences regarding dependency rejection? He links to 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.

d19:08:45 might be a good alternative to Component framework if you want to avoid DI/protocols everywhere 😃


but it's still just calling out to state


@ 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.

👍 4

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 captures the essence of DI, although it's not really described as such. I also made a minimalistic tool in the same vein 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.


Injure is cool and I like it


Ah, so you're talking about declaring rather than actual argument passing.


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.

👍 4

@vemv essentially, the author is advocating for not testing the parts of code that currently call stateful things.