What do product and sum types have to do with data modeling?
Product and sum types allow us to exactly model any number of states with a lot of flexibility.
►► Audio, Video, and Transcript available: https://lispcast.com/what-do-product-...
►► Subscribe on iTunes: https://itunes.apple.com/us/podcast/t...
Transcript
What do product and sum types have to do with data modeling? By the end of this episode, I hope to answer that question, because I missed it when I talked about product and sum types the last time.
Hi, my name is Eric Normand and I help people thrive with functional programming. A few episodes back, I talked about product and sum types and explained what they were. I'm not going to go over that again, because you can go listen to that one and get it all.
I did get a couple questions about why I mentioned them, and what they have to do with data modeling at all. I realized I had explained what they were, but I totally forgot to talk about why you would want to use them at all. Now, I'm going to try to explain that.
Let's look at a simple case, all right? You're modeling this domain, and there's certain cases that you have to capture. Let's say that there are 10 cases.
Now, one thing you could do is simply enumerate all of the cases. Let's say, it's 10 states that the system can be in. You can enumerate them so you have one type that has all 10 cases. That would be a sum type that has the 10 different constructors, let's say.
There's other ways you can hit the number 10 as well. You could have two 5s. You could have two types, let's say a five each, and then have an either between them. An either is a sum type, so it's going to sum the five and the five. That gives you 10.
Now, another way you could do it is, you could have a two times five, so not five plus five, but two times five. Meaning, you use a product type where the first, let's say a tuple -- a tuple is a product type -- so, the first element of the tuple has two cases and the second element has five. Now you've got the 2 x 5 and you've got 10 again.
This is the kind of thinking that you can do once you realize that there are these product and sum types that you can use.
Why do you want to target the number of cases exactly? I've done a very detailed analysis for my book of this. It's not going to be in the book, because it's boring.
If you've got too many cases in your domain model, that means a case that doesn't really exist in the real world but it exists in your software, like it's possible. Let's say you did 5 plus 6, and so that's 11.
There's 11 cases, but one of them shouldn't be used. At some point, you're going to either use it or have a conditional to make sure it's not being used.
Conditionals add complexity to your code. If you have extra cases, you're adding complexity.
What if you had 9 cases when there's really 10 cases in your domain? If you only have nine cases in your code, that means that you're probably going to be overloading one of those cases to make up for it.
You're probably going to be using one of those cases in two different ways and your code is going to have to have a conditional to figure out which one of the cases it really should be.
In both cases, in both of those situations, you are missing the perfect fit between your domain model and the domain itself, and adding complexity because of it.
An example of something very simple, an almost silly example of a time when you might have a misfit is...and this happens a lot. You have something like you're reading a sensor, like a thermometer.