I break down two perspectives (their features and their methodologies) for the three most common paradigms. I also explore why paradigms are so easy to argue about, and what we can do about it.
We address the question directly, but then look deeper to the beliefs behind the question.
We explore some of the background behind the meaning of the word abstraction and why we do it.
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.
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.
The world may be mutable, but people have been using the notion of immutability to build reliable systems for a long time.
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.