What is the primary superpower of functional programmers?

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?

Transcript

Eric Normand: What is the primary superpower of the functional programmer? Hello, my name is Eric Normand. These are my thoughts on functional programming.

I'm organizing this book and my editor asked me a really good question, it's just a prompt to help me think about my material. The question was, "What are the superpowers that you need to teach? What ability or skills are people going to have after they finished the chapter, the book, the section?"

I've been thinking a lot about the superpowers. What's the most important one? How do you organize these superpowers to be taught?

The primary superpower, as far as I can see...The primary meaning it's fundamental. The other ones all stem on this one. The primary superpower is the ability to see actions, calculations and data, so real quick. I have other episodes on what these are. I could spend a whole hour talking about the difference between actions, calculations and data, but real quick.

Actions are things that affect the world and are bound in time. That's how you tell that they're an action. It depends on when you run it or how many times you've run it. If you send an email twice, that's different from sending that email one time, and it's different from sending it zero times. That's actions.

https://twitter.com/ericnormand/status/1077957544818237440

Calculations, you can carve out parts of your program that don't matter when they're run or how many times they've run. All the additions that you do in your program, when you add two numbers, that doesn't matter when you do it, because you're going to get the same answer no matter what.

Inside of that, there's data. Data definitely doesn't matter when you run them. I mean you don't run them. They're inert. They can't be run. What they can be is interpreted. In general, we're dealing with immutable data, data you don't change.

https://twitter.com/ericnormand/status/1076870438444298240

It's timeless in a deeper way than calculations are, because calculations do require you to run them at some time to use them, whereas data is just inert. It just sits there and regardless of whether you to read it or not, it's going to be there.

The ability to see these things, to distinguish between them, is very important in functional programming. You need to be able to see that this action depends on time, or this part of my code is timeless, and I can run this as many times as I want. That's the primary superpower. If a programmer couldn't do that, I couldn't call them a functional programmer. That is very important.

https://twitter.com/ericnormand/status/1072219931603816448

I've really been thinking about whether that's true, whether this is primary. I can't imagine a Haskell programmer who couldn't do this. I couldn't imagine a Clojure programmer who couldn't do this. This is just basic to every other skill.

You cannot identify that this part of the code is going to have a side-effect. That "It depends on how many times I run it" versus "This other part is a pure function, I can call it as many times as I want" versus, "This is just some data that I'm going to interpret in different ways, in different situations."

I think that I'm on to something, but I need your help to let me know that this is make sense. I would love to hear that it doesn't, because I'm writing this book and I don't want to put this in there if it doesn't make sense. Is there something even more fundamental than that? I think it makes sense, what I'm wondering if it is primary.

Please, if you have any thoughts on this, you can reach me on Twitter @ericnormand. I'm also eric@lispcast.com on my email. Thank you so much. I'll see you later.