28 Apr 2019

Components feel so not FP

At work we're writing most of the new stuff using Clojure. That's been going on since before I started working there, and from the beginning there's been exploration of style and libraries, yes, even of frameworks (ugh!). Now there's discussion of standardising. The discussion is still in its infancy, but it prompted me to start thinking about what I'm come across in the code base we have now, what I like and what I dislike. The first thing that came to mind was how our different services are set up. I mean set up internally. Like, what's actually in the main function (or in -main, since we're talking Clojure). In many services we use Stuart Sierra's component, in a growing number of services we use integrant, and in one we use mount.

The current discussion is going in the direction of integrant, and I don't like it!

AFAICS integrant suffers from all the same things as component (the author of mount has put it into words better than I ever could in his text on mount's differences from component') plus one more thing to boot: systems are "configured into being". It's touted as "data-driven architecture", I tend to see it as architecture defined in a language separate from my functions. The integrant README says that one of its strengths over component is that

In Integrant, systems are created from a configuration data structure, typically loaded from an edn resource. The architecture of the application is defined through data, rather than code.

Somehow that statement makes me think of OO and DI frameworks. I suspect the above paragraph is just as true with the two replacements s/Integrant/Spring/ and s/edn/XML/. I'm not convinced this is a strength at all! My experience with DI frameworks in OO is limited (I've never used external configuration), but the enduring impression is that it's unwieldy. In particular it was very far between cause and effect of errors. So far this is true for integrant as well.

Also, it makes me think of "functional in the small, OO in the large"^1, which is a comment coming out of the f-sharp world. Maybe there's a connection here. Maybe "OO in the large" is something that resonates with OO-turned-FP developers. Maybe that means it's only a quesiton of time (and exposure to FP) before they embrace "functional all the way"? Or, maybe I'm simply missing something crucial.

In any case I'm going to have to take a closer look at mount in the near future. I'll also have to take a look at its brother yurt, and at its distant cousin mount-lite.

Tags: clojure functional_programming