Thoughts on Functional Programming Podcast

Higher-order functions are used a lot in functional programming. They are functions that take other functions as arguments or return functions as return values, or both. You’ll probably be familiar with map, filter, and reduce, which are higher-order functions. In this episode, we go kind of deep on them.

I’ve noticed that people go through a certain journey when learning functional programming. I’ve classified it into three levels: 1) Distinction between Actions, Calculations, and Data; and learning to use them effectively 2) Higher-order thinking; and building abstractions from higher-order functions 3) Algebraic thiking; building coherent models with a focus on composition. This is a work in progress and I’d love your input.

My book is coming out soon in early access. It’s called ‘Taming Complex Software: A Friendly Guide to Functional Thinking’. But what is ‘functional thinking’? In this episode, I explain the term and why I’m no longer redefining ‘functional programming’.

I often have to remind myself that we make information systems when we are programming for a business. My natural tendency, due to years of education, is to begin by creating a simulation. But this is not what we need to do. Instead of simulating a shopper going through a store, we need to model the information transfers that were captured in the pre-digital information system of pen-and-paper inventory and order management.

You confuse them a lot, and it’s not your fault. They are similar in that they are both about order. Associativity is about the order of operations, and commutativity is about the order of arguments. We go through some examples to help clear up the distinction.

We run our software for its effects, so effects are necessary. We can’t write 100% pure code. But I contend that some effecting code is better than others. In other words, there is a spectrum from bad effecting code to good effecting code. Even if you can’t turn an action completely into a calculation, you should still strive to minimize implicit inputs and outputs.

Inverses are everywhere. They let us undo an action. For instance, I can open a door and close it. Why do we want to do this? Because there are things I can do with the door open, and other things I can do with it closed. We need this same flexibility in our computer programs.

There’s a lot of discussion on Twitter about whether Node has a repl or Python has a repl. Do they have repls? How can we tell? Well, my opinion is that what’s important is how it’s used, not a set of features.

Haskell is very competitive with C, and on some benchmarks, it is faster. How is that possible? With all that Haskell does on top of the raw C code, how can it possibly be faster? In this episode, I talk about two advantages of Haskell that can make it faster than C.