Functional programmers often talk about creating layered designs, where each layer represents a coherent level of abstraction. It’s a way to organize your code.
Thoughts on Functional Programming Podcast
An off-the-cuff stream of Functional Programming ideas, skills, patterns, and news from Functional Programming expert Eric Normand.
People ask me how to keep functional code organized. It’s a good question but my answer is so simple, it feels kind of silly saying it: I keep everything in one file, and split it up as it grows.
Does the term “design” make sense in the context of code? I discuss Sandi Metz’s definition from her book Practical Object Oriented Design in Ruby.
In OO languages like Java, people tend to make new classes more than they reuse existing ones. In Clojure and other FP languages, we tend more on the side of reuse. How do we develop that habit?
What is the easiest way to make an existing functions more functional? It’s quite a simple technique and you can apply it today.
Functional programming gets its reuse by creating small components that are very well-defined. Small means they’re probably generally useful (like lists). Well-defined means they are easy to build on top of.
Functional programming divides the world into actions, calculations, and data. Actions are hard to test by definition, and we explore why.
A few episodes ago I talked about how things compose. But I didn’t get into how things compose across domains. For instance, how do actions compose with calculations? Let’s get into that, and what it reveals about our work as functional programmers.
People often say that functional programming is a “declarative paradigm”. I push back against that categorization. I simply think the word is mostly meaningless.