Where does structural similarity come from?

In a recent episode, I said structural similarity comes from the algebraic properties of the relationships between things. But that's not the case. Rotislav mentioned in the comments that it actually comes from the structure in the relationships. I explore that idea in this episode.

Transcript

Eric Normand: Where does structural similarity come from?

In this episode I'm going to explore this idea that when we implement a real-world process on the computer, there's got to be something that gets shared. I talked about this in a previous episode but I got a really good YouTube comment, so I'm going to go even deeper and further, and deliver a correction of what I was talking about.

My name is Eric Normand, and I help people thrive with functional programming.

I got this YouTube comment from — I hope that I don't butcher the name but I will, so I apologize in advance, if I do — Rostislav Svoboda on YouTube commented on my episode called "Why are algebraic properties important?"

In that I said that when we implement something, something is being translated from the real world to a digital representation. Something has to be the same or we wouldn't get the same answer.

Just like if I count apples and then I count the same number of oranges, I should get the same answer even though one is apple and one is orange. Something is the same between those two piles of fruit.

I was talking about in that episode that it must be that we're capturing a bunch of the properties of those operations. When we're counting, we're really adding one, adding one, adding one. We must be capturing this commutative property or the associative properties.

If you do enough of the properties, the important ones for doing that algorithm or that process that you're doing, you will succeed in translating the important stuff.

Rostislav brings up a good point, which is that the relationship itself, the function itself, is what gets translated over and the properties are just kind of incidental. When I'm counting apples and I'm counting oranges, I'm adding one each time. It's the same operation that I'm doing.

When I'm translating, say, an accounting practice from a person's head who's doing stuff in the real world, and I'm translating that into...They're writing stuff in notebooks and looking stuff up. They've got a process that they're doing. I'm translating that into a digital algorithm, a digital program. Is it the properties of those operations that make it work?

What he's saying is, "No, there's more structural similarity there." There's a relationship between the numbers on the page and the total, meaning it's the sum.

Now, I have to have a thing that is...It might not be a sum. It might be something else when I translate it, but it is structurally similar to it. It turns out it's going to be a sum because you want to get the same number answer. You have to use the same operation.

Maybe that's not a good idea, not a good example, but the properties of it are just incidental. They are not what you want to translate. For instance, if you used multiplication, it's still commutative and associative. You're not going to get the same answer so it's not going to work.

Is translating the properties the thing to do? Probably not, but there are structurally similar operations going on, the relationships, the functions that you're using. Functions and relationships and math are...A function represents a relationship between the input, the argument and the output, the return value or the domain and the range, if you will.

There's a relationship. It defines a relationship. If you define a structurally identical relationship, then you can use that in your software.

Here's an example of a structurally similar relationship. In the real world, when we talk about the days of the week — Monday, Tuesday Wednesday, Thursday, Friday, Saturday, Sunday. In the computer, it doesn't know, it doesn't care what the days are called. Usually, it's like zero, one, two, three, four, five, six.

Why is it possible to use numbers to represent days? It's a totally different system. Why is it that in the human level interaction we're using named days, and in the computer, we can use numbers?

There's a little translation if we need to print out the name of the day, that's easy, but why is it that we're allowed to do that and get the same answer?

The reason is, structurally, there is an order to the days of the week, the names. We know the order, we memorize it as kids. We know that it cycles around, and we can apply that same thing to the numbers.

There's an order to the numbers zero, one, two, three, four, five, six, and we can make it cycle around. The easy way to do that is using mod. You just mod it by seven. Now, you get a cycle as you add one.

These two things are different. They are not the same, but they share enough structure to get at the important thing, which is that there's an order and it cycles. That is different from the algebraic properties. He was right, I was wrong about that. It's not the algebraic properties. Those are kind of incidental.

They're still useful to know if you've captured what you need to capture, but you can't just say, "This operation has these properties. This other operation has the same properties. That means we can interchange them." It's not true, you can't. There needs to be some deeper structure in it, like I was talking about with the days of the week.

All right. Thank you, Rostislav, for that insightful comment. I really appreciate that.

There's a lot of people out there who have thought about this much deeper than I have. I'm very curious, and I'm very grateful that people would take the time to help me understand this better, and in turn help everyone understand it better. Thank you so much.

If you enjoyed this episode, you can find all the past episodes at lispcast.com/podcast. There you will find audio, video, and text transcripts of all of the past episodes. You'll also find links to subscribe and how to get in touch with me on social media, including email, YouTube, Twitter, LinkedIn.

I love this. I love the discussion. I love the back and forth. This is so great. Thank you so much for commenting.

This has been my thought on functional programming. My name is Eric Normand. Thank you for listening, and rock on.