Thoughts on Functional Programming Podcast

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.

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.

Part 2 of the functional architecture series. When we’re structuring our functional software, we want to isolate the actions from the calculations. We can do that using the Onion Architecture, which has layers like an onion. The center of the onion is your domain model, then around that are your business rules. Finally, around that is your interaction layer, which talks with the outside world, including the database, web requests, api endpoints, and the UI.

Part 1 in the Functional architecture series. The Stratified Design, which I called “layered design” before, is a way of architecting your code as a series of layers of meaning. It’s a common way of organizing your code and structuring your application.

The biggest companies in the world are investing heavily in functional programming. From Facebook building React and Reason, to Apple pivoting to Swift, to Google developing MapReduce, functional programming is gaining traction. But why? I go over four hypotheses and evaluate them.