Why is Functional Programming more expressive?
This is an episode of The Eric Normand Podcast.
Subscribe: RSSApple PodcastsGoogle PlayOvercast
I explore the idea that Functional Programming is more expressive than Procedural Programming (and why it is) using a metaphor of a pizza master.
Eric Normand: Why is functional programming more expressive than procedural programming?
Hi, my name is Eric Normand and these are my thoughts on functional programming.
I want to explore this idea using a metaphor. Imagine there's a master pizza chef and he's trying to explain how he cooks pizza. How he makes pizza. He publishes books of recipes, lots of different recipes.
The recipe lists all these steps to take. First do this, then do that. First, you mix the flour with the water then you leave it out for two hours. Then you knead it so many minutes.
Of course, you could replicate a lot of those pizzas that he makes and simulate his knowledge by just following these steps.
In theory at least, if you followed his steps over and over and you followed multiple recipes, you would approximate his...you would learn the patterns. You have a pattern matching brain.
You would learn the patterns and see what's going on, in theory. In reality though, there are books and books written on how to make dough. Even the different kinds of flours that are available. There's a lot of deep knowledge going on there that you could never replicate in a series of steps.
Now, you might see the metaphor, but either way just to be sure, I'm going to explain it. In procedural programming, and I'm including object-oriented programming in this because it is just a series of what methods are you going to call.
In procedural programming, all we have to express are steps, steps to take. We know it's too incomplete so we're not going to go there. It's a [indecipherable 2:45] discussion. You have this series of steps that can make a pizza or that can calculate an answer, can figure out what emails to send.
Do whatever needs to be done to keep your car on the road. The programmer — the person writing that program — has all the knowledge in them. They're not able to express that knowledge. Only are they able to list steps that the computer can take to perform the calculation they want. What functional programming does is, it gives you a way to express deeper knowledge of the domain.
That deeper knowledge — is by analogy — is stuff like the chemistry going on in the flour when you're kneading the flour. How to determine the right amount of rising your dough needs. How the combinations of flavors in your toppings are going to affect the final experience of the pizza.
What you're able to do as a functional programmer is take these little bits of knowledge. These tiny little eensie-weensie bits of knowledge, thousands of them and put them together into a whole.
Instead of a series of steps that would get you there except, "Oh, the humidity was off," and that wasn't part of the steps. Or the flour you bought was a little old or a little dry and so it changes how it's going to rise.
Your steps can never capture the entire variety of what could possibly happen in the world. Now, it's not that your functional program can capture all that either. It simply captures more. You're able to compose these things up in a much richer way than you can compose procedures up.
Which is basically just do one procedure then the other. Or you can build one procedure out of two other procedures. In functional programming, the ways of combining them are basically limited only by your imagination. That's a metaphor I've been thinking about for how to explain how functional programming is more expressive.