Clojurians Log v2

In the data-oriented programming approach (the one Rich taught us), code and data are coupled in the same sense that a frontend and a backed are coupled via an API definition. If the backend breaks the API definition, the fronted code has to be updated. But they are coupled in a loose way. Meaning that one doesn’t care about the implementation details of the other

> "one doesn’t care about the implementation details of the other" This is abstraction, the distinction between an interface and an implementation, and both, Clojure and Java, support it. The functions in Java and Clojure that manipulate those records and maps are coupled to the definitions of these records and maps. > One benefit of Clojure approach is that the namespace doesn’t have to “import” the class definition for Customer It is not because you don't have to import the class customer that it is not coupled. In Java, the coupling is visible because, like you say, you have to "import" the Customer class. And the functions that take a customer as parameter specify the type of the argument. In Clojure, you don't have to "import" the Customer class. This is actually a drawback of because in doing so you create a hidden coupling. Specs are one way to make this coupling visible. Coupling is a concept at the logical layer of software, not at the concrete implementation layer. For a definition of these layers, see http://www.pathsensitive.com/2018/01/the-three-levels-of-software-why-code.html Don't get me wrong. It is much better to represent records as maps rather than Java classes, but it has nothing to do with abstraction or coupling.

@cgrand Could you rescue me here? I couldn’t find the proper words to answer @me1740’s questions 😬

@cgrand You are so convincing with your sophisticated vocabulary (strawman argument, discrete getter, typed generic getter, payload evolution, external state, concretions …). I wish my french was as refined as your english 😊

@me1740 the connection between loose coupling and representing data with maps was made by Rich Hickey on his talk https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/ClojureMadeSimple.md (Around 0:10:29).

I'm not seeing the connection between loose-coupling and using maps. He says that we need flexibility and loose-coupling, I think we all agree on this. Then there are some quotes. Then he talks about the fact that we should recognize that what we manipulate most of the time in our programs are records, simple data, and that we don't need fancy abstractions on top of it. I agree with this. When your program manipulate records of data then you need to reuse the same abstraction for all your records (like a Clojure map). Sometimes though, it will help you to create new abstractions to control the complexity in your programs. You have to find the right balance between reusing existing abstractions and creating a new one. You can do the same in Java by using the Map abstraction to represent your records instead of creating the Customer class but it is much more awkward to use, especially with static typing. Regarding coupling, wether you have customer.getName() or (:name customer), your function in Java and Clojure will be coupled to the interface of your customer. There is just no way around it.

Couple of remarks (since @viebel summoned me): keywords namespacing is important and one keyword could be seen as 1 interface. You couple against what you use vs coupling against the whole thing.

Agree in this case. That has an impact on coupling. The corresponding operation in Java would be to put the subset of method(s) in an interface and have the function depends on this interface rather than the class.

Accessing data in a map via a keyword is fundamentally different than accessing data in an object via a method (or a member). The only information that needs to be known in order to access data via keyword is the name of the field. That’s how I understand the loose coupling. Of course there is a coupling. The question is: is the coupling loose or tight? I’d like to claim that accessing data in a map is loosely coupled with the representation of the data while accessing data in an object is tightly coupled with the representation of the data.

But I cannot find the proper arguments. I’m not even sure that I formulated my claim properly.

But I’m quite sure that when Rich talks about loose coupling, he refers to “just use maps”

I would suggest that you define the terms before making a claim. To make sure you say what you mean and to make sure people don't misunderstand you. Coupling is about propagation of change. Two things are coupled if changing something in one thing requires changing something else in the other thing. The change propagates from one to the other. Two things will be tightly coupled if every time you change the slightest thing, you have to change the other thing as well. And two things are loosely-coupled if you have a lot of degrees of freedom when changing one thing without impacting the other thing. A lot of software design is about finding the right level of coupling to make sure that things work together (there will be a mimimal amount of coupling) while still being able to change each thing independently (without having to change any of the other things).

I am not sure that your definition of loose coupling is accurate, at least that’s not what Rich Hickey means by loose coupling. Richen often claims “we should program the insides of our systems like we progam the outsides” The interfaces between two components inside a program should be the same kind of interfaces between two programs. When two programs agree on an API, each one of them is free to change the implementation providing that they don’t break the API. I’m pretty sure that this is what Rich means by loose coupling. Now, how the API between program should be formulated ? In terms of data. Not in terms of code (like DCOM etc…) According to Rich’s philosophy, we components inside a program should define their API in terms of data. Not in terms of classes and methods.

> When two programs agree on an API, each one of them is free to change the implementation providing that they don’t break the API. I’m pretty sure that this is what Rich means by loose coupling. That's what I also mean by loose coupling. The changes you make to your implementation do not propagate to the user of your API as long as you respect the contract of this API. By "define an API in terms of data", do you mean making sure that the functions of your API take data as input and return data as output? If so, it might make sense for software modules that deal with information records but there are APIs that do other things that simply manipulating information records. When Rich says "use maps", he means that when we want to represent records of information, we should use maps. And I totally agree with that. But it doesn't mean that we should use maps of static data everywhere. Take an API like Datomic that Rich designed himself. Would you call the database value that you pass as argument to most of its functions data? Thankfully you don't have a gigantic map containing all the data in your database. The API is a set of functions that lets you query this database value.

I think we agree on most of the things

@jayzawrotny I think your example illustrates the benefits of separating code from data. Could you have gained the benefits you mentioned by storing bid data in various data classes like BidForVendors, BidForUsers …?

If you know all the possible contexts from the beginning, it may be possible to get some of those advantages with subclasses. But realistically, new contexts emerge which means a continuous cycle of moving methods and attributes from the base class into the subclasses. The one wall you might hit is if you want to perform a sequence of actions across contexts. So if an admin closes the bid, we may want to send closed emails to both the vendors and users. With that separate Clojure setup, that’s trivial to do since you have a single bid object hash-map that can be passed between functions across any context. With subclasses, you would need to create new instances of the next subclass you need:

(ns company.admin.bid.api
  (:require
   [company.db :as db]
   [company.user.bid :as user]
   [company.vendor.bid :as vendor]))

(defn close
  [bid]
  (let [closed-bid (assoc bid
                          :closed true
                          :status :closed)]
    (db/update! db/conn bid)
    (user/send-closed-bid-email closed-bid)
    (vendor/send-closed-bid-email closed-bid)))

I see. I think it’s called the ClassAWithThisAndThat problem

You need to create a class for every combination of fields!

That’s insane 😱!

What’s even more insane is that Java folks don’t seem to be aware of this insanity