How variants can reduce complexity скачать в хорошем качестве

How variants can reduce complexity

►► Audio, Video, and Transcript available: https://lispcast.com/how-variants-can... ►► Subscribe on iTunes: https://itunes.apple.com/us/podcast/t... If we don’t limit it, complexity will get out of hand. One way to limit complexity is by collapsing the number of possible states down to a few known states that we know how to handle. Transcript So if we've got this exploding multiplicative cases where each time we have a corner case, or even any kind of branch, we multiply it with the other branches. It seems like our software would explode with complexity and we'd just never get out of it, so how do we? My name is Eric Normand, and these are my thoughts on #functionalprogramming. One way I want to talk about today that we can handle this complexity -- at least limit it somehow -- is by using a limited number of cases. If you have some function that has seven different cases, a branch in it has got seven different cases, and who knows what happens in each of those branches. Each branch could have three, four cases itself because it calls another function that has branches in it, how do we ever deal with the complexity at all, if that's what's happening? There's this giant tree with branches. One of those branches is going to execute and it's going to have our answer. Well, the answer is that we limit the number of cases that we will return. What that means is if you have 10 branches, you might say, "Well, there's only going to be three possibilities coming out of here." Each of those 10 branches has to return one of those three cases. In that way, you're taking this thing that could have, you know, if you multiplied it all out, it could have 20,000 branches, it could have 1,000 branches and you are limiting it to three cases, so you've reduced the complexity by bucketing. You're bucketing all those different possibilities into a smaller number. This is the thing that a language like Haskell has an advantage for. They have what are known as discriminated unions, also known as variants, where you define a new type that has different constructors. Each constructor is a different case that has the data required for that case. You have different ways of...an example is different ways of communicating with someone. You might have communication method as a type. The three cases are email with a string, phone number with a string, which would represent the phone number, and then maybe you have their address, which is some more other complex type that has like the street, the city, the state, the zip code, that kind of thing. What you're doing is you're defining a limited set of ways to communicate with someone that your system can handle. What that does is it means that no matter what branch you're on, you're going to get back a valid way to communicate with someone that your system knows how to handle. It could be 20,000 branches, 20,000 different paths through your code to find an answer. It's going to be one of those three. That's a powerful thing that we should constantly be trying to reign in this complexity because it happens...the complexity multiplies. It multiplies too easily without any work on our part. It's almost like entropy is on the side of complexity. We need to put energy into bucketing those things and making decisions about which one of these three are we going to handle. When I see code, I often look at it in terms of how much complexity is this eliminating or creating. Very often it's just creating complexity. For example, there's a pattern that I think of as generating complexity, which is when a function returns different types and each type is supposed to mean something different. It might return a string. Let's say in the case of...Well, I'll get to that later. Let me finish this example. If we have different types we might say, "Well, a string is going to be the name of the person but if we don't know the name we'll return nil. Maybe they have multiple names. We'll return a list of names in that case." Now, the problem is you've generated three cases and one of them is super complex. The case where you return a list of names. Now you're just opening up the door for complexity because a list has this other problem which is it can be empty. That's a case that you might not have thought about. You also have the case where like, what do you do with all those extra names, right? You're just passing on the decision to some other piece of code. Then that code has to have branches. It has to have all three of these branches again, the string, the nil, and the list, and it has to figure out what to do with it. What you want to do is think about whether you can reduce this. Just go through each one and say, "Well, nil is obviously not good enough as an answer to cover all three cases." It's not. I mean, you can't represent anything with nil. A string might be.