You’d expect the longest and most costly phase in the life cycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay th
I’ve been working with Clojure and most code is written using pure functional style. As a concrete example, Pedestal HTTP server has around 18,000 lines of code, and 96% of it is pure functions. All the IO and side effects are encapsulated in the remaining 4% of the code.
This has been a common scenario for the vast majority of Clojure programs I’ve worked on in the past decade. Core of the application does data transformations using native Clojure data structures. This is where all your interesting business logic lives. The interop lives at the edges and typically used for stuff like database drivers, HTTP servers, file access, and so on.
And I completely agree regarding immutability being the sane default.
I find that there are two major problems with OO. First is that it takes a lot of effort to learn how an API works because you have to pass object graphs around, and each object is a unique snowflake in terms of methods and behaviors it has. So, you often have to learn how dozens or even hundreds of objects are intended to be used.
Second, is that each object is effectively a state machine, and your application is structured as a graph of interdependent stateful objects. This makes it effectively impossible to reason about any non trivial application because all these relationships are too big to keep in your head. The only thing you can do is fire up a debugger get the application in a particular state and inspect it. Unfortunately, this is just heuristic since it’s hard to guarantee that you’ve covered all the paths leading to a particular state.
Meanwhile with FP library APIs become data focused. You call a function, pass it some data, get some data back, and that’s all you need to know. Data is both transparent and inert in nature. You don’t have any behaviors associated with it, and you don’t have to know what methods to call. The scope of information you need to keep in your head is drastically lower because you’re able to do local reasoning.
As an FP-fan interested in Clojure, how does one track if functions are pure in Clojure? I had assumed this was not possible, due to it not being statically typed (although I gather there is 3rd-party support for gradual typing).
There is nothing stopping you from making an impure function, but the language naturally guides you towards writing code that’s composed of a bunch of functions that transform data. Clojure also has explicit containers for mutable data and those have their own semantics, so you can’t accidentally cause mutation.
It’s also worth distinguishing between different kinds of side effects. One type of effects is doing things like logging, which in my experience are generally harmless. The type of side effects that I tend to worry about are the ones that couple functions together via mutable references.
And yeah, Typed Clojure library lets you do gradual typing, but it hasn’t really caught on with the community so far. Most people prefer using runtime contracts with Spec and Malli.
Thanks - I was just wondering how this somewhat precise statistic was obtained.
Otherwise, all that makes sense generally, though I tend to model logging as an effect in statically typed languages with effect systems. But I agree that it isn’t the most important thing!
I’m not sure how the statistic for Pedestal was obtained, don’t recall if the talk mentions it or not. There are static analysis tools for Clojure like clj-kondo that can provide these kinds of insights. You could see what parts of the code are pure based on what functions get called for example.
Sorry - I didn’t realize your original link was to the video and not the project. After watching it (good talk!), I found the clip in question. It seems like he is just saying that 96% of the codebase is functions (of any sort), not that 96% of the functions in the code are pure.
OK yeah, I misremembered the exact phrasing. You’re right he doesn’t say the functions are pure necessarily.
I don’t doubt that it’s possible to use FP for everything, I’m just pessimistic about our whole industry adopting it in the near future. It has frequently taken decades for the mainstream to catch onto new developments.
Oh yeah I completely agree that FP is nowhere close to being mainstream. Lots of mainstream languages are bolting on functional features, but there’s a big gulf between doing that and using an actual FP language. That said, there are lots of places where you can use FP professionally, and it’s not too hard to find a job where you can work with a language like Clojure. My experience with Clojure in particular is that demand for devs is higher than the amount of people who know Clojure, and that translates to higher salaries and better perks.