What kind of software is functional programming not suited for?

Functional programming cannot be suited for everything, right? Well, let's not be so sure. Functional programming, like imperative programming and object-oriented programming, is a paradigm. It is a fundamental way to approach software. There are many languages that fall within the umbrella of FP. It is quite possible that everything we know how to do in software, we know how to do well with FP, the same way we know how to do it with imperative and with OOP.

Transcript

What kind of software is functional programming not suited for? We will go over this question and explore it in some depth by the end of the episode. Hi, my name is Eric Normand, and I help people thrive with functional programming.

This is an important question, because if we are being honest with ourselves, we're going to find places where something isn't a good fit. If it's a good fit for one thing, there's going to be a bad fit somewhere else. To say that a thing is good at everything is probably to delude yourself.

I want you, my listener, to have a more balanced view of what's going on, so we're going to explore this question. I'm going to make reference to other paradigms, object-oriented paradigm and imperative paradigm, and we'll see. We'll see how they all do as paradigms.

The question is, what kind of software, what applications, what domains, what kind of context is functional programming not suited for? My first impression is this is like asking what object-oriented programming is not suited for, or what imperative programming is not suited for.

Even though I don't generally endorse imperative programming, like in the same way I endorse functional programming, it's hard for me to think of a domain where imperative programming is not great. I don't feel like I'm being biased by saying that I think that there's something wrong with the question. I want to go into why that might be.

The thing is, these are general approaches. These paradigms are general-purpose approaches to software. They are more like a world view from which to begin your exploration of a problem domain and how you might solve it. It's not like they're mutually exclusive.

Their ideas certainly aren't mutually exclusive. They just kind of set a groundwork, a framework, in which you're going to continue exploring.

They're a whole system of thinking, and so it's hard to say that some kind of application wouldn't do well in imperative programming. It's a system of thinking. It's a place to start. Likewise with object-oriented programming. It's a place to start.

Just to be super clear, when I'm talking about the three major paradigms, object-oriented, imperative, and functional, I'll quickly give a nutshell description of these as paradigms.

Imperative programming turns everything into a sequence of steps. That is your main programming unit is a routine or a subroutine. You can break up a sequence of steps into further steps, call those and name them, and refer to them that way. You could see that this is a generally applicable paradigm.

A lot of people say, "Functional is really good with math." A lot of high-performance math routine software, is written in an imperative style. It's written in Fortran, so it's really hard to make that argument that functional programming is better at math than Fortran.

Object-oriented programming, there's basically three main concepts. There are objects, which hold state and accept messages, there are the messages that are sent between objects, and there are the methods, which are the code that runs when the message is received.

In this way, you create this network of objects that communicate with each other. The computation happens through the dispatch of different messages and what each object does with the messages it receives.

Likewise, you look at software written today, a lot of it is written in object-oriented programming, in an object-oriented style. It spans all sorts of domains, all over the spectrum. It's really hard to say that it's not suitable for this stuff.

People have built systems to do aircraft engineering, to embedded systems, to simple web applications. Everything is built in this OO framework.

I'm going to say the same for FP, that there's really nothing that FP isn't suited for. Real quick, functional programming as a paradigm begins with three things, the three main concepts -- actions, calculations, and data. These are mutually exclusive categories that everything falls into.

[mrwisek]

Cool broadcast. I like the distinction between the paradigm and the various languages that facilitate programming in the paradigm. Functional programming on GPUs with good performance was not something I expected to hear about.

[robehickmann]

What would be more useful to talk about are lower level ideas, like how garbage collection is a problem in game engines as it causes unpredictable performance, or how data layout in memory has a BIG impact on performance, see 'data oriented design'.