What are side-effects?

In functional programming, people often use the term side-effect. But what does it mean? Side-effect is any external effect a function has besides its return value.

►► Audio, Video, and Transcript available: https://lispcast.com/what-are-side-ef...

►► Subscribe on iTunes: https://itunes.apple.com/us/podcast/t...


Transcript

What is a side effect? Hi, my name is Eric Normand. These are my thoughts on functional programming. If you like what you hear, please hit subscribe.

What is a side effect? This is a very important concept in functional programming. Side effects are anything that is outside of the scope of a normal pure function, otherwise known as a mathematical function.

If you remember from high school algebra, a mathematical function maps the domain to the range. It maps the arguments to the return value as we would say as programmers. It is a mapping that is timeless, meaning it doesn't matter when it's run.

It's not having an effect on the world. It's a mapping just by definition. It just maps this to that. We do that a lot with our functions. We write a function that takes X and doubles it, and it returns that doubling.

Every time we call it with three, we're going to get six, every time. It's not dependent on anything outside of the argument that we pass it. Imagine a function that has some other influence over that answer.

Or imagine every time we call this function, something happens in the world. You could imagine that number six getting written to a file or getting sent over the network stored in a database or logged to disk, printed onto the screen.

Now, it's not timeless. Now, it's not really this relationship between inputs and outputs. It's a relationship between inputs and outputs with something else happening, which is called the side effect.

You call this to get the number six out, but something else happens that maybe you didn't know about, maybe you didn't want it to happen, or maybe that's exactly what you wanted to happen. You don't even care about the return value.

In functional programming, we call that a side effect. It's a side effect as opposed to just an effect. The term is used loosely. As these terms go, it's complicated. The term is used loosely, but in general it's used to say that this isn't the main reason to call this thing.

The main reason to call double is to get six out when you pass in three. This other thing happens, too, so it's a side effect. You could call them effects. If you have the print function that prints to the console, it doesn't have a return value really.

It's really weird to call it a side effect, but people do. They use the term loosely, like I said. In functional programming, we try to isolate those effects. Separate them out from the mathematical functions.

Double is a perfectly good mathematical function. You could write it once and use it for the rest of your life. Maybe you want to optimize it or something, but it's going to work forever, regardless of context.

It's something that you could put into a utility library and basically never touch again. Your context of where things are running, maybe you don't want to print it, maybe your log system changes, maybe the database you're going to store it in changes, all that stuff is way less timeless than this relationship between the argument and the output.

There's a good reason to separate that out. Timeless stuff, it changes less often. It's easier to test. It's easier to debug. Imagine testing this thing. If you're going to test a function, you're going it run it multiple times with different inputs.

You're going to test easy cases, some hard cases. Maybe you just put it through its paces and you test a hundred, a thousand cases. Imagine if it was writing to disk or hitting the database.

If it's hitting the database, you have to make sure the database is running. If you are writing to a file, you got to make sure the file exists and is open. Your test become a lot more complicated.

Whereas this easy return value function, it's all it does. It's all in outputs. That's so easy to test, so easy. That's one of the reasons why we like to isolate them. The hard stuff in programming where most of our bugs come from is all having an effect outside of itself.

All the writing to disk, the sending a message over the network, the reading from the database, the drawing stuff on the screen, all of that stuff is hard. Responding to user input. This is where the complexity lies.

As much as possible, we want our code to not depend on that. You need to do all those things. That's why we run our software but if you can isolate those things and manage them...You isolate them so that you can manage them. Whereas all this other stuff that's just calculations, that's just functions in the mathematical sense, all of that stuff doesn't need managing in the same way. It's way easier.