Clojurians Log v2

https://www.manning.com/books/data-oriented-programming?utm_source=viebel&utm_medium=affiliate&utm_campaign=book_sharvit2_data_1_29_21&a_aid=viebel&a_bid=d5b546b7  update: Chapters 3 and 4 were released today where I illustrate: 1. The power we get when we represent data with generic data structures (“just use maps”) 2. How to manage state with immutable data Get 50% off with the discount code mlsharvit2 valid through April 15. Chapter 3 illustrates my understanding of Rich hickey’s view of data (a.k,a just use maps!) Looking forward to get feedback from other Clojurists about my attempt to make Rich’s message “tastable” (and testable) by non-Clojure developers

For the discussion, let's agree that coupling is about the amount of knowledge pieces of code need to know about each other. I think it is related to saying that changes propagate because if A needs to know something about B then when this something in B changes, A needs to change as well. So I don't think we're too far off in our definitions 🙂 Now, if you want to be precise, you need to explain what it is that you don't need to know in case of maps or data interface. Or at least give an example of knowledge that is required in one case and not the other.

Another way to think about it. In your Java version, if you passed an instance of a Map with the customer data as key/value pairs. Would you say that it is comparable to the Clojure map in terms of coupling or different?

Mostly, with two differences (most signgificative first): The immutability brings you peace of mind that the map isn’t going to change under your feet (which an immutable facade doesn’t bring you). It’s temporal decoupling: you can stash the map for later use without having to care about the object lifecycle (eg pooled/reused object or mutable event in UI). Namespaced keys (that you can emulate in Java).

Yes, definitely, the Clojure map has many advantages. It is also not a type casting nightmare to get a value out of the map 🙂