[asdfasgasdgasdg]

I'm not sure I agree here. There's not too much value in testing these two or three lines of code in the get-article handler. And the passing around of compositions of higher order functions can get confusing. There are cases where an approach like this is warranted but I would say that there needs to be a significant level of complexity before this makes sense.

Having a protocol for your data layer and an in memory implementation of that for testing can make sense, especially when your real data store is expensive to bring up, but I would try to minimize the number of seams like this in my system. Each one introduces cognitive overhead due to indirection, so you should use them judiciously.

[dwohnitmok]

Yes Clojure is all about first-order functions working on simple, concrete data structures.

Pervasive use of protocols and custom, user-defined higher-order functions I would argue is unidiomatic Clojure and creates long-term pain as you end up with opaque functions being passed around that can't be inspected at the REPL and a lot of tricky "fitting functions together" that is made difficult without a static type system. You sometimes need them, but you should reach for them very judiciously.

There's a reason Clojure emphasizes data over functions (and both over macros).

[d3nj4l]

Yes - sometimes you can go too far in the quest for abstraction. I've seen a ton of over-enterprisey people build gorgeous abstractions with perfect testability and dependency management, only for it to be used only ever in one context in one way. I lean towards WET first before extracting an abstraction, if that.

[deobald]

The argument for pure functions holds in a real system; these particular signatures will be familiar to anyone who's built a few Clojure web services. In reality, some of the functions listed (say, `get-article`) would disappear entirely into a system-specific convention. There's a balance to be had between the number of seams the team is managing directly and those which, by their creation, mean less cognitive overhead. The seams then exist only if they are required, as certain handlers might choose to diverge from the conventional functions used in a generic way.

It's of course not easy to see that next step from the article, since it doesn't eliminate any code by creating pure functions. But even in a toy example, there is value of creating pure functional abstractions. In some codebases, you might even see the team lead segregate pure functions by namespace: "Pure stuff over here, tainted stuff over there." In those situations, teams try to reduce impure surface area -- in this case, anything that touches the `db` namespace.