Clojurians Log v2

The standard advice is "just use maps" - the motivation for that is given in section 3.4.2 of this document: https://dl.acm.org/doi/pdf/10.1145/3386321 It sounds to me like it's time to stop studying though, and just make the connect 4 program; the simplest version does not use records or protocols.

@mbk.racket What's your previous programming background? If you feel the urge to reach for records and protocols "naturally", I'm thinking you're used to an OO approach perhaps?

To me, a "game state" is data—a map. A "game tree" is also data and also probably just a nested map of data. Most of the class "Gang of Four" Design Patterns end up being "just" higher-order functions in Clojure. So it's data + functions all the way down.

records and protocols are for performance. the problem with using them prematurely is that they are less flexible than the other abstraction mechanisms (functions and maps) and introduce unneeded ceremony

When I was learning, one thing that this advice used to confuse me with is I thought it also meant that we shouldn't be modeling entities. But that's not the case, it's just that you can model entities using plain maps and it's just less complex, and more flexible.

(defn make-car
  [& {:keys [model make price color]}]
  {:type :car
   :model model
   :make make
   :price price
   :color color})

(defn make-car
  [& {:keys [model make price color]}]
  {:type :car
   :model model
   :make make
   :price price
   :color color})

(defn reduce-price-by
  [car percent]
  (update car :price #(* % (- 1 (/ percent 100)))))

P.S.: And idiomatically, you don't go creating "accessors" like "update-model", "update-price" or like "get-price", "get-make", because since it's just a map you can just do "(:price car)" to "get", and since it's immutable anyways you can just do (assoc car :price new-price) or use update if it's dependent on the current value. So you would only add functions that are doing more complex things and modeling more conceptual operations. Also for protecting invariants, like validation that sometimes is done in setters and getters, that tends to be more that you validate the whole entity after a series of changes. So you might have a spec for car and then say (s/valid? ::car car) instead of having each "setter" validate that you are setting to something valid.

@hhausman Thanks so much for the article. I look forward to digesting it.

@didibus Thank you for your very concrete reply. I completely agree that the map approach would indeed be adequate. I clearly had a mental goof in my original message where I somehow equated using plain old data with having a single amalgamated nested data structure like in my web server example. D'oh!

FWIW, I will mention that at least one well regarded source apparently disagrees with the conventional wisdom: In "Clojure Applied", Ben Vandgrift and Alex Miller introduce records specifically in contrast to maps as a preferred way of modelling domain entities. And the way I read it, ISTM this is not just for performance benefits, but for more clearly expressing intent to other readers of the code.

that book came out before the core.schema namespace (iirc Alex was even on the team that implemented schema). I hope I will be corrected if this is wrong, but my understanding was that one of the goals of core.schema was to separate the aspect of communicating design intent from the implementation details. there's a good talk from Rich where he talks about the rationale and references RDF as an influence

Yes, I think records initially were for that, and before them structs. But the idioms evolved where most people eventually realized as I showed that really you don't need a special construct, maps + destructuring easily fulfills that contract. It's not universal and some people like records, and they are usable as maps as they implement the map interface. But they come with a baggage of generating a Java class under the hood (in other dialects this might not be the case). That means records are meant to be: 1. A definition of the shape of a record with a name/doc to describe your application entities 2. A way to create an efficient map-like structure that has faster field access than a map (no hash lookup instead its direct field access) 3. A way to leverage the JDK host first parameter type polymorphic dispatch which is faster than Clojure's multiple dispatch through multi-methods, by instead being able to implement interfaces or extend protocols to them Some things to know: 1. Dissoc will convert it back into a map and return a map of the record minus the removed key 2. Assoc of additional keys (not defined in the record) will be stored in an internal map on the record, so no longer as fast as field access 3. Assoc/update of keys you defined return a copy of the record object with the fields updated. 4. Meaning records are still immutable, but don't do structural sharing like persistent map does, instead it does a shallow reference copy. So why the idiom evolved to prefer maps then? 1. As you see, it's easy to accidentally start with a record and get a map back, you think you can just filter, merge, and so on as if they were a map because it supports it, but as soon as you do that you get back a map. If then you expect that type dispatch still works you'll be surprised it doesn't because you now have a map and the record is no longer of it's original say Car type. 2. They're not data, so serialization and deserialization brings all the complexities of object serialization. 3. Some other little details like that I'm forgetting This is why people now suggest to only use them if the performance gains from direct field access over map key lookups or for JDK based type first arg type dispatch really brings speedup to your use-case. Remark you can have maps implement protocols as well, so you can still define protocols for maps. Protocols are not frowned upon, when you need an abstraction of multiple functions working together protocols are great. That said, oftentimes just functions can work over many maps making them generic, or multi-methods can also be used to branch a function's implementation for different map shapes. Lastly, that leaves one thing about records that's nice, the defrecord is a convenient way to define the shape and name/doc of your entities. For that Clojure has evolved to using Specs such as clojure.spec or some prefer some 3rd party libs that are of the same idea. The spec is your definition with name of your entities. Defrecord is still nice in that it will also create a constructor conveniently for you. But that can be your own macro you make or really it's not that much trouble to write your own make-foo constructor to construct a map of your specs. If you have any questions about any of that feel free to ask. Given your experience I thought I could get more technical and detailed right away.

Oh, and I'd say, even Specs, generally people tend to add them later, because a map constructor function with destructuring is often legible enough in showing you the name + doc + shape of your entities. Specs add value once you want to be a lot more detailed, like specifying the type and allowed values of each key, and include validation of more complex invariants.

@noisesmith I think you meant to say clojure.spec and not core.schema ?

you are correct

Also, plain map can now participate in protocols via metadata, pretty huge.

> Remark you can have maps implement protocols as well, so you can still define protocols for maps. Protocols are not frowned upon, when you need an abstraction of multiple functions working together protocols are great. That said, oftentimes just functions can work over many maps making them generic, or multi-methods can also be used to branch a function's implementation for different map shapes. As a hack comedian once said: That's gold Jerry! Gold!

Quoting the text at that link: > You can find the latest driver https://central.sonatype.com/artifact/org.postgresql/postgresql/versions. The page is painfully slow to load on my end though...

Ah, finally - here's a direct link to the JAR: https://repo1.maven.org/maven2/org/postgresql/postgresql/42.7.13/postgresql-42.7.13.jar You can find it if you first go to the Maven page of the driver, then click Browse to the right of a specific version.

Cool, thanks :) i am Kind of glad that it wasnt the clojure part that made feel stupid in this tutorial:smile: