for me, one of the biggest value propositions (pun intended) from clojure is that everything is built using immutable data structures. having the core data structures be immutable makes it easy and idiomatic to build libraries out of pure functions. pure functions are really great building blocks for writing complex programs that are reliable, flexible, and built-to-last. obviously, there's lots of other cool stuff, but I think that's one of bigger differences compared to other languages/ecosystems.
That’s a fair point, though I’ve already written a page for functional programming principles and specifically covered immutability and composability. This topic seemed a bit more challenging to convey so wanted some review. I’ll adjust how I frame it though so it’s not like its THE differentiating factor, but I don’t want to underestimate the importance of that because it wouldn’t matter if the pieces were simple if it was written in incomprehensible gibberish.
i'm unfamiliar with the term "Domain-Driven Development" so I'm not sure I fully understood the post. It seems like the post already assumes some knowledge of Domain-Driven Development practice and jargon.
That’s very helpful, definitely a trapping I wanted to catch early. Thank you!
Tried to add a quick intro to domain driven development terminology. If that still doesn’t’ cut it, I’ll keep the intro and start over the rest from scratch.
oh, I've also never used notion. not sure how to look at the latest version
Refresh should do it if you’re in browser
Testing is also something to consider a plus imo. Its fundamentally easier to test systems built around flow of data than ones based around mutation of objects
truthfully, I don't think explaining domain driven development as a concept works as a justification - though your explanation is so far very well written and clear.
The real justification can come from describing the nature of what you are trying to build and the different directions your product can grow in the future. Then show the pros/cons of clojure in that context.
For instance, if you are making an app that handles data flow heavily you can make the argument that the programming model more closely matches the essence of the task than the competing options on the JVM. Then there are benefits to the JVM that outweigh other dynamic options, etc
There are real tradeoffs to clojure, so for internal docs its important to clearly outline the ones you considered and the way you weighted the pros and cons.
That's a good point about tests, which I hadn't considered, as well as about DDD not being a justification. One nuance here is that the codebase is already written in Clojure so this serves as a more specific why it was chosen. To your point though DDD is the result of being able to describe what we are trying to build and how it can adapt over time so I should focus on those aspects. It's sort of explaining why https://youtu.be/Tb823aqgX_0 happened where just defining the class names and relationships was more code than to get it to run in Clojure.
If its already built, then maybe treat it as a reflection? Like "We started this system in clojure because I wanted to and thats basically all the reasoning I needed but we ended up seeing these benefits with [ticket #] where alternatives would have required XYZ"
(very much not an authority on anything, so piles of salt on any suggestions I make)
Not a bad idea. That document is a sub-document of https://www.notion.so/jayzawrotny/DRAFT-Why-did-we-use-Clojure-for-the-Azure-Cloud-Services-a59a7034a4aa46c7b608e64b9a6f1267. I already intended to create a page on Clojure Tradeoffs.
I have a funny joke about the relationship to clojure and java but i don't want to invalidate all the work java did either x)
I doubt you will find too many people on this channel offended by such a joke 🙂
Would that be off-topic in #off-topic? :confusedparrot: