What is functional thinking?

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'.

Transcript

Eric Normand: What is functional thinking? In this episode, I'll talk about the topic of my new book. My name is Eric Normand. I help people thrive with functional programming.

I have a new book, which will come out, eventually. I'm publishing it with Manning. It's about functional programming.

The reason I'm talking about it now is that it is soon going to come out in early access, which means, you'll be able to read it online, an ebook format. Before it comes out, you'll be able to read the chapters that are done. I wanted to start talking about it. Because it's this close, it's very close now.

The title of the book is, "Taming Complex Software — A Friendly Guide to Functional Thinking." I wanted to talk about what functional thinking is, what I mean by it. I started this podcast about 18 months ago. It was made to start thinking about this book, and the ideas that I wanted to put into it.

I proposed a new definition of functional programming. You can go back to those early episodes, where I reason out why I need a new definition of functional programming. As a short explanation, the standard definition of functional programming says that, "It is programming with pure functions and avoiding side effects."

There's a lot of truth to that definition, but I feel it makes a lot of assumptions that are not explained in the definition. It is also problematic for other reasons. It scares people. Because when they learn what side effects are, how can you write software if you're avoiding the main purpose of running our software in the first place?

I wanted a definition that would clarify it, and put this definition as a smaller part of a bigger picture. As an example, the definition makes a distinction between pure functions and side effects, but it's not explained in the definition. I feel this distinction that's being made is very central to functional programming. It should be part of the definition.

Why should it be part of the definition? Because no other paradigm makes that distinction. No other paradigm talks about the difference between side effects and pure functions. You can double check. They might talk about it later, but not as part of the definition. Usually, it's with a nod to functional programming.

I believe that that should be baked into the definition. I've been in discussions with a lot of people. A lot of people agree with me. A lot of people say, "Oh, the definition is just fine." These are just the implications of this definition. That's what I'm talking about the implications. They're not primary.

I've been in a lot of discussions. Some people say, "It's so clarifying to hear you make that distinction as the primary thing." Anyway, I was continuing along with this idea when the publisher finally came up with a title that everyone at the company, the publishing company that's working on the book liked, which I read before, Taming Complex Software — A Friendly Guide to Functional Thinking.

The functional thinking got me thinking that maybe I don't need to be so antagonistic about this definition. I'll just call it something else. Call it what I'm explaining something else. The thing is no functional programmer would say that distinction between side effects and pure functions is unimportant.

Everyone would say it's important to functional programming. The disagreement was merely in, do we need a new definition? I don't know if I really want to have that fight. I don't want to fight that fight. The fight would be with people who are already sold on functional programming.

In a certain sense, you could say, it's good to pick fights, because it creates marketing, a buzz about your book. It's like a little controversy that gets people talking about the book, and so then they might buy it.

What I have been thinking about more and more is that it's not the discussion that I would have with people would be among people who are already bought in to functional programming. It might be good for marketing. I decided I didn't want to do it. I liked the functional thinking idea that it's not really that different. It's just that it hasn't been defined.

I can make it whatever I want. Basically, it's the same stuff as I was saying before, but with a different term. It's basically how functional programmers think, which is what functional programming is, functional programming as a paradigm. Paradigm means the ways of thinking and approaching problems and the concepts.

It's the same thing, functional thinking and functional programming, but no one has defined it yet. I can do what I want with it. It's also focusing more on the thought processes, as opposed to specific functional programming techniques or features, which I think a lot of functional programming has gone.

A lot of what people understand when you say the term functional programming. They're already like, "So, it's about monads?" I'm like, "No, that's not where we're going. We're going much more fundamental." It's about this distinction between pure functions and side effects. That's an update. That's what functional thinking is.

When you see the title, you'll know where I'm coming from with that. The main distinction that functional programmers do make that distinguishes them from other programmers and other paradigms is identifying side effects, identifying pure functions, and identifying the other implied thing, which is the data.

The definition does not say anything about data. It just says pure functions. I've asked people about that, and they say, "Oh, well, it's implied because you need to add something for the functions to act on." That's obviously data. It's there. No one would disagree that you need data as separate from pure functions.

They just never mentioned it in the definition. Functional thinking explicitly calls it out. I'm calling them actions, calculations, and data. Actions, they're not the same as side effects. They're more like impure function.

You got impure functions, which I'm calling actions. You got pure functions, which are calculations. You've got data, which should be immutable. That's my ideas on functional thinking.

Look for the book. It should be coming really soon, the next few weeks. We're counting it in weeks, now. We had to pull all the little pieces together. Then, someone at Manning has press to a button so it goes live. It's happening.

They don't like to promise this, but the idea that they're shooting for is one chapter every month, a new chapter released every month, or, at least, a major update to an existing chapter. I'm starting with three chapters, chapters one through three. Then I hope to hit that target of one chapter a month. I've been working at that pace. It looks good.

I'm going to sign off now. You can find this episode and all of the past episodes and all future episodes in the future at lispcast.com/podcast. You'll find video recordings, audio recordings, and transcripts. You can read it if you prefer reading.

You'll also find links to subscribe, or contact me on social media. If you want to follow me there, get in touch with me. I much prefer a discussion than simple follow. It's all there. Go to lispcast.com/podcast to check it out.

All right. I'm Eric Normand. Keep on programming functionally, and rock on.