Yeah, there's a tradeoff here which you need to consider based on the context. E.g., I much preferred medley.core/map-vals over the handwritten juxt-style mapping because it was shorter and much more readable even after I had seen the juxt-style idiom many times. As a bonus, it was also more performant. And with clojure 1.11 we have update-vals so it's now a straightforward choice 🙂

I agree, i also have a hard time making sense of tense Clojure code and appreciate the introduction of meaningful let symbols or function names…

I can't go back in time and be new to Clojure again, so I really appreciate you taking the time to write out your thoughts and providing that perspective! I have ingrained habits of thinking, so sharing how you see things helps me stretch my thinking out of my well-worn paths.

One of the ways I view things in my own head is the separation of the mechanics vs the intention. Complex expressions, even if they are built up with core and common idioms, don't implicitly communicate their intention. By putting that expression in a function and naming it, you can label the intention and purpose.

Definitely one approach is to add comments to express the intention, and I think comments can be very helpful, but this is where the "building up the vocabulary" part comes in. Those functions begin to create a space of expression for that problem space. Those functions turn into views of the data ("extractors"), important questions to be considered ("predicates") and define the operational space ("updates", "reducers", "transforms"). I tend to put all these functions together (co-located), and I can get a clear picture of what matters in that information model.

We get into specifics about this in Eps 15 - 19. In that, we develop a "computational space". Look here for the code: https://clojuredesign.club/episode/018-did-i-work-late-on-tuesday/

The information model is a sequence of maps which all contain :date, :start, :end, and minutes. From there we built up a "vocabulary". Consider this function:

(defn day-of-week
  [entry]
  (jt/day-of-week (-> entry :date)))

At first that function might seem a little silly. Why make a function for that at all? Why not just use jt/day-of-week (:data entry) whenever you need to know? Turns out that vocabulary starts to compound.

(defn day-of-week?
  [day entry]
  (= (day-of-week entry) (jt/day-of-week day)))

Which otherwise would be:

(defn day-of-week?
  [day entry]
  (= (jt/day-of-week (-> entry :date)) (jt/day-of-week day)))

And then there is:

(defn weekend?
  [entry]
  (or (day-of-week? :saturday entry)
      (day-of-week? :sunday entry)))

Which otherwise would be:

(defn weekend?
  [entry]
  (let [day (jt/day-of-week (-> entry :date))]
    (or (= day (jt/day-of-week :saturday))
        (= day (jt/day-of-week :sunday)))))

These are pretty trivial functions for a bit of a toy problem, but there is already an aspect of clarity. I won't belabor the point much more, but you can see that weekday? could start to get ridiculous if we didn't depend on some other vocabulary:

(defn weekday?
  [entry]
  (not (weekend? entry)))

Also, as a new reader in the code, you now know that this problem space considers days of the week, weekends, and weekdays to be important. There are so many other dimensions of time that could be important, but in this code, apparently, they are not really all that important.

Again, this is pretty simple, but if I encounter total-minutes in the code, that immediately tells me what it is, even though the equivalent is fairly trivial code:

(->> entries
     (map :minutes)
     (reduce +))

@U01PE7630AC I hope that helps explain my thinking a bit more. I'd love to show more complete code, but I don't have anything at hand that I can share. I'll just make due with what I've got for now.

Actually, I can give you a real world example. This is from an application I developed.

I wrote code that has to manage camera and microphone inputs for a web-based application. It has to deal with all sorts of edge cases. I created a determine-action function that will return the "right" thing to do based on the current state of the manager component.

I might be wrong, but I'm guessing you go figure out all of the important edge cases even without much in the way of commenting. This is an example of working at the "problem space" level, not the "mechanics" level.

(defn determine-action
  "Returns a tuple of the action to take and the reason for the action."
  [data]
  (let [{:keys [blocked? media-devices media-input waiting-for-media?]
         :cache/keys [settings url-settings]} data]
    ; Order matters because the first match wins. Be careful not to move a
    ; condition earlier than its guard conditions.
    (cond
      (nil? settings) [:no-op :settings]
      (nil? url-settings) [:no-op :url-settings]
      waiting-for-media? [:no-op :waiting]
      blocked? [:no-op :blocked]

      (not (enabled? data)) (if (active-media? data)
                              [:stop-all-media :not-enabled]
                              [:no-op :not-enabled])

      (nil? media-devices) [:detect-devices :no-devices]
      (missing-input? data) [:no-op :missing-input]
      (need-permission? data) [:ask-permission :need-permission]

      (media-needed? data) [:start-inputs :need-media]
      (device-removed? data) [:start-inputs :device-removed]
      (not (selected-device-is-active? data)) [:start-inputs :selected-not-active]

      ; Camera settings can be applied on the fly without restarting the input.
      (camera-settings-changed? data) [:apply-camera-settings :camera-settings-changed]
      (settings-changed? data) [:start-inputs :settings-changed]

      :else [:no-op :default])))

Of course, to understand how the state is represented, you have to look elsewhere. What constitutes a "missing input"? How do we know "media is needed"? Look at the functions. You can always come back here to see all the things that matter and how they are related to each other.

Those are some fantastic examples, @neumann! Thanks for taking the time to share those. Making "silly small functions" definitely makes sense, and I tend to do that in other languages as well for my day job. For example, here are two Python helper function I wrote today:

def extract_dict_key(dict, key):
    return [d[key] for d in dict]

def transform_list_to_string(list, separator=' '):
    return separator.join(map(str, list))

@U01PE7630AC Neat! I'm not totally sure what the first one does, but in the second case, it's telling me that "this is the way the list is represented as a string". In Clojure, I tend to use "arrows" in my function. Eg. some-entity/->str.

Yeah, the first one could definitely do with a better name. That was the best I could come up with in a hurry 😅 It basically returns a list of values which correspond to a particular key in a dictionary (kind of like a Clojure map… ish). I'm using it like this:

def get_google_account_names():
    '''Get a list of all account names (unique ids).'''
    google = get_google_api_interface(
        get_google_credentials(),
        service_name='mybusinessaccountmanagement',
        service_version='v1',
        service_discovery_url='')
    accounts = google.accounts().list().execute()
    return extract_dict_key(accounts['accounts'], 'name')

['accounts/******************020',
 'accounts/******************098',
 'accounts/******************872',
 'accounts/******************021',
 'accounts/******************112']

I think this post from Eric Normand is related to the discussion: https://ericnormand.me/issues/purelyfunctional-tv-newsletter-434-re-combination-of-parts I like how it discusses the tradeoffs, notably the argument that "optimizations" (whether it's performance or better design) could be achieved more easily if you don't hide everything behind an abstraction barrier: > But concision can make things easier to rework at a deeper level. > You are freed from the confines of the original domain modeling. And sometimes, you need that freedom to make a breakthrough

@neumann The advice you outline here is great. I'm going to very specifically try to add some flavor to it but realize this might not be the stew you needed in your case: Assuming the "jt" in

(defn weekend?
  [entry]
  (let [day (jt/day-of-week (-> entry :date))]
    (or (= day (jt/day-of-week :saturday))
        (= day (jt/day-of-week :sunday)))))

(require '[clj-time.core :as t])
(require '[clj-time.predicates :as pr])
(pr/weekday? (t/date-time 2014 1 26))

(def weekend-day #{:saturday :sunday})

;;mocked fn 
(defn day-of-week [x] :saturday)

(some weekend-day (-> entry :date day-of-week)) #note not repl tested :(

@U0DJ4T5U1 It might be worth clarifying that @nate and I didn't miss the fact a "weekend" function already exists in the Java Time wrapper. The whole example is a bit of a toy problem. We were using it to try to provide concrete examples in a familiar problem domain. Since it's a podcast, we don't have the benefit visual illustration during the episode, so we wanted to pick something already understood. I suspect that many well-understood problems already have robust libraries available. Most of the time I spend programming in the "real world" is spent wrestling with a unique problem domain solved by the application (or set of libraries) I'm developing. I've found the concept of "building up language" to be extremely useful there. I hope the toy problem was useful enough to illustrate the concept without being too distracting in terms of "reinventing the wheel."

Thanks for the clarification.