Composition is an important idea in programming, and Functional Programming brings it to the forefront. But what does it mean to say things are composable?
Global mutable state is one of the biggest drivers of complexity in software systems. We tackle a definition and how to reduce our reliance on it.
Functional programming, from one perspective, is just a collection of habits that affect our programming. I've identified the cues for those habits and a routine for replacing imperative code with functional code.
It's common that adding more layers of abstraction or indirection will make things slower. However, React and ClojureScript make web pages faster than doing it by hand -- essentially programming the bare web. The lesson is that if you choose your layers well, they can actually make your system faster.
Object-oriented dispatch is contrasted with functional dispatch, but they are shown to be two one-dimensional projections of the same two-dimensional data. Clojure does not provide the two-dimensional representation, but does interesting things to transcend the one-dimensional views.
Functional programs follow a simple rule: never write on the same paper twice. Imperative programs are free to define their own rules. Both have interesting consequences.
Functional programmers often use the term "reason about code". It's not very well defined generally, but I use it myself to refer to our ability to use our real-world intuition in our own code.
Code style is important, but way less important than content. Yet everyone talks about style because it's easier. Let's talk about content.
The world may be mutable, but people have been using the notion of immutability to build reliable systems for a long time.