Ep 119: Summary Time

Each week, we discuss a different topic about Clojure and functional programming. If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack. This week, the topic is: "pure state and set models". We look at one thing over time and many things at the same time. Our discussion includes: Patterns of pure models Working with a pure model in the REPL How pure models help you understand the application Real world vs pure model What is a state management model? What is a collection work model? When to use those models and the information they produce Selected quotes You don't want to people to read your code and then curse your name... Or come at you with sharp objects! What is the secret sauce of the application? Your pure data models! A pure model for managing state? Pure state. That seems like a contradiction. I think someone came up with the acronym ACID for a reason: heartburn or bad trip, either way, that's the best case scenario for managing your state in a database. We're not talking about managing state in some kind of external system, we're talking about managing information in time. If you have information that changes in time, then you need a pure data model for state. The future is a function of the past. Your current state goes into a function with some context (an event, an operation, etc.), and your new state comes out. The point is it's pure. This is pure information, and there are no side effects. A pure model gives you the vocabulary to discuss it. It gives you information about what's possible and what's not possible. We want to name our filters and reductions because we work in the realm of semantic information. We can begin to compose these little primitives, these little parts, into larger and larger things. Clojure core is like the engine, but it's not the mechanism that you use to work with the model. You put that mechanism in the model functions, and then you're able to work at the higher semantic level: the application domain, not the data domain. Why not name it? Even if you use it once, giving it a name helps document its intent and purpose, and it helps you understand the code when you come back to it later. It's much better than trying to read a clojure.core composition and deduce the intention. Names are for us. Links "Reentrant Coding" Series Ep 114: Brand New, Again Ep 115: The Main Event Ep 116: The Main Focus Ep 117: Pure Understanding Ep 118: Pure Parts Ep 002: Tic-Tac-Toe, State in a Row Ep 017: Data, at Your Service