Thoughts on Functional Programming Podcast

People often ask ‘what are the design patterns of functional programming?’ A common answer is that categories from category theory, like monads and functors, are the design patterns. But is that true? I explore the consequences of that answer.

People often say that functional programming is more expressive. But how does FP achieve that? The key is by making things first-class.

Pure functions have no effect besides returning an immutable value. If that’s true, then how can we use them to represent changing state?

JavaScript programmers talk a lot about callback hell. In this episode, we look at the phenomenon from a functional programming perspective.

We look at a metaphor to explain the three domains in functional programming: actions, calculations, and data. I hope the metaphor makes some things clearer and can help people explain fp better to others.

Is there something that functional programmers do that, without that, you couldn’t really call them a functional programmer? Is there a power that all other powers are dependent on?

Some might say that functional programming has the answers to solve the problems of concurrent, parallel, and distributed systems. But is that true? We explore what FP has to offer.

We talk a lot about composition, but what does it mean? Each domain (action, calculation, data) has its own way to compose. In this quick episode, I explain each one.

Postel’s Law states that a program should be liberal in what it accepts and strict in what it sends. What does this have to do with functional programming? How can this help us reduce complexity?