What is a race condition? We look at what causes race conditions and some ways you can avoid them.
Thoughts on Functional Programming Podcast
An off-the-cuff stream of Functional Programming ideas, skills, patterns, and news from Functional Programming expert Eric Normand.
What are pure functions? I explore the definition, the term itself, and why functional programmers like pure functions.
I got a lot of questions about how to apply the Onion Architecture to particular situations. In this episode, I try to answer it with a specific example.
In stratified design, we are looking for layers of meaning, each one implemented on top of the last. But how do you go about building those in an existing codebase? While it remains more of an exploration than a step-by-step method, we can still describe some techniques that help find them. In this episode, I talk about four of them.
There is always a tension in our programs between raw data and meaningful information. On the one hand, data is meaningless alone. On the other, we want to treat it as a thing with real semantics that constrain its usage. How do we live with both of these at the same time?
React (and other frameworks like it) will re-render their components when the data for those components change. Is that functional? If it were pure functions, then things would only render when you called it. It’s being affected by changing data. My contention is that it’s not really functional (as in pure functions). It’s reactive programming. But reactive borrows many ideas from functional.
Event Sourcing is an architectural pattern that shows up in many mature information systems. This is the fourth in my three-part architecture series.
It’s tempting to use mutable state in your algorithm. It’s so convenient! And we’re so used to it, if we come from an imperative paradigm. But we must remember that there is always a way, even if it’s not immediately obvious. I go over two ways to implement an algorithm without mutable state.
Part 3 of the functional architecture series. The universal process pattern is a schematic representation of software. For a software process to be useful, it needs input, it needs to calculate something from that input, and it needs to have some output or effect on the world.