Why do we need a Theory of Functional Programming?

Though I have gotten good reception for the theory in general, a few people have asked me why we need a theory. More people have told me I'm complicating Functional Programming, which should be a simple idea.

Transcript

Eric Normand: Why do we need a theory of functional programming? Why is it important to develop this whole thing that I'm doing right now? Hello, my name is Eric Normand. These are my thoughts on functional programming. As you may know from previous episodes, I am developing a book called "A Theory of Functional Programming."

An idea is to set out the definitions and relationships in terms and ideas of functional programming, write them all down and then carry them to their logical conclusions. People have asked me why I think it's important. Some people as like, "Oh, yes, we definitely need that."

Some people have questioned whether functional programming isn't much simpler than I'm making it out to be, that I'm complicating it by talking about...Some people say that functional programming is really simple. It's programming with pure functions.

I've talked a little bit about why I think that's inadequate already. Just to summarize it, what about everything else? What about data? It's not sufficient as a definition. If you're just programming pure functions, that's lambda calculus. That's not what we do. If you have data, you've already broken your definition.

We need to talk about data. If we're going to talk about data, we might as well talk about side effects. Also, functional programmers do talk about side effects. Let's not even talk about them programming. They have a definition of side effect that they use, and other paradigms don't.

If you read a book on object-oriented programming, they don't talk about side effects. That's not part of their thinking. They're talking about messages, classes, and has-a, is-a, all that stuff. Side effects are somewhere else on their radar. Maybe they get to it like the command queries separation thing.

They're not thinking about mutable state, and global state, stuff like that. I mean, they're thinking about it, but it's secondary to their paradigm, whereas it's primary to the functional programming paradigm. Someone should write that down.

The most common question I get is like, "Isn't functional programming just much simpler than I'm making it out to be?" The other question is, "Why do we even need a definition?"

The answer that I have to that is that if you look at the object-oriented programming — redirect the discourse about it — they have all these rich books that have defined terms, that have laid out the best practices, the worst practices, some common ideas, patterns, idioms, all these things.

When they talk about it, they have this common lexicon. It's a wonderfully rich language that they can use to discuss code, and to teach people how to code, when they're teaching. We don't have that in the functional programming community.

All of the books that I have found on functional programming are either about a specific language — it's mostly about the language — or are highly academic. They are talking about a category theory, lambda calculus, or something like that.

There's not a book that's meant to start the discussion about what it means to do functional programming, what are the important ideas, what are their definitions, how do we start taking those ideas, and building bigger ideas on top of them. Just lay out the field.

We don't have that. I want to do that. I'm poised to do that. The theory that I've been talking about has the potential to do that. I'm crossing my fingers that enough people will care for that, that it will have some impact.

This stuff is out there already. What I'm saying is I'm not bullshitting. I'm not making this all up. I'm merely talking about what I've seen, what I've read people do, what I see in code. I'm trying to codify it into something coherent. I hope it is the start of something.

I would love for people to take the ideas in my book, run with them, and say, "If we apply that in this domain..." What's an example that I can give? You have the book design patterns. It's like a seminal book in the field of object-oriented programming. Whether you agree with it, or not, l don't want to get into that discussion.

This book has given people a vocabulary to talk about common patterns, and show people what is possible at a higher level when you're doing object-oriented programming. You don't have to use for-loops. You're not using an object, or a class as a C struct. You should treat it like something higher level.

You have a visitor pattern. Instead of using a for-loop, and going through a link list, you should have some interface on your list, so that you can do a map over it. This is the thing that that book talks about. I don't know if people actually read the book. They all know the book. They know what design patterns means in general.

Other people can write a book called "Design Patterns for Legacy Systems," and "Design Patterns for XYZ," and "A Look at Design Patterns in..." They can write up these other books. They don't have to establish the idea of design patterns.

In another book where it is talking about object-oriented programming, you can reference the visitor pattern, the interpreter pattern, because someone has defined it. We need a set of books like that, or at least one book to get that started as industrial functional programming, not academic.

Academic is great, but then they've already got their books. I want something for the industry that sets it on a good course.

All right. That's why I'm developing the theory. That's why I'm writing a book. These ideas need to be talked about. We can't just rely on these super simple definitions that don't actually cover what they claim to cover. They're just pulling into this middle academic world, where it's actually a virtue to have a simple definition like, "We just use functions."

Pure functions. Can program with only pure functions. It sounds great in an academic context. It's great in an academic context to make your definitions smaller, because then, you can control it. You can know exactly what the consequences are to meet.

In layman's industrial expert context, where things have to get done, you're not looking for something to be picked apart by peer reviewers. You're actually looking for something useful that can bring it to the next step, to the next level of understanding. That's what I'm trying to do.

All right. I'm sure you disagree with me. You need to tell me about it before I write this book. Tweet me at @ericnormand, with a D. Yes, I'd love to hear from you. Let me know. I'll see you then. Bye.