Just one improvement imho: I’d personally prefer if users could provide their own map manipulation functions rather than just relying on predefined ones; what do you think?

There is no actual difference between [1] and [1'] or between [2] and [2']. Which you prefer is a matter of taste. My purpose in writing the macros was simply to demonstrate that macros can be used to formalize a repeated syntactic pattern. I’m not sure I’d even use these macros myself, unless I felt like they really added to the clarity of the code.

One other possibility, which I failed to mention in the article, is that abstracting this pattern into macros could allow alternate implementations. For example, perhaps the macros could be made clever enough to use only local variables and omit the map parameter altogether for better performance. I don’t actually know if this is possible in this case, but it’s interesting to think about.

Shouldn’t side-effecty stuff like logging be isolated from functions containing transformation logic? Are explicit return calls idiomatic in clojure? How does [1] really differs from [1'], and [2] from [2']? I’m not sure which is shorter.

[1]
(defpipe compute-step2 [delta]
  (return
   (assoc-in [:x :y] 42)
   (:update delta * 2)
   (:set gamma (+ delta 100))))

[1']
(defn compute-step2 [{:keys [delta] :as m}]
  (-> m
      (assoc-in [:x :y] 42)
      (update-in [:delta] * 2)
      (assoc :gamma (+ delta 100))))

[2]
(defpipeline compute
  compute-step1
  compute-step2)

[2']
(def compute (comp compute-step2 compute-step1))

(defpipe foo [a b]
  (log "This is foo")
  (if (< a 100)
    (return (:update b + 100))
    (return)))

Also, a typo, I think: in `compute-step1`, shouldn’t the `set` be a `:set`?

Will you package these code as a library?
It does great help to me. I am looking for way that I can use it in my application.