WEBVTT 1 00:00:00.080 --> 00:00:04.759 Imagine you're curled up in your favorite chair right deeply 2 00:00:04.799 --> 00:00:06.759 engrossed in this fantastic mystery novel. 3 00:00:06.799 --> 00:00:08.279 Oh it sounds like a great afternoon. 4 00:00:08.359 --> 00:00:11.560 Yeah, exactly. You're following the plot, picturing the characters. But 5 00:00:11.640 --> 00:00:15.279 there's just one massive problem. 6 00:00:15.359 --> 00:00:16.199 Okay, what is it? 7 00:00:16.320 --> 00:00:18.839 Someone else is standing right next to you frantically flipping 8 00:00:18.839 --> 00:00:21.239 the pages of your book back and forth while you're 9 00:00:21.280 --> 00:00:21.960 trying to read it. 10 00:00:22.039 --> 00:00:24.839 Oh wow, that sounds incredibly frustrating. 11 00:00:24.440 --> 00:00:26.879 Right, I mean, one second you're on chapter three and 12 00:00:26.879 --> 00:00:28.640 then boom, you're staring at the epilogue. 13 00:00:28.679 --> 00:00:30.760 Yeah, that would drive me crazy, exactly. 14 00:00:31.199 --> 00:00:36.399 And that chaotic, unpredictable, pull your hair out mess that 15 00:00:36.520 --> 00:00:41.039 is exactly what happens inside your software when concurrent programs 16 00:00:41.240 --> 00:00:42.479 share mutable state. 17 00:00:42.799 --> 00:00:46.920 It really is the ultimate concurrency nightmare. You know, you 18 00:00:46.960 --> 00:00:49.640 have one thread trying to read a sequence of data, 19 00:00:49.960 --> 00:00:53.119 and then another thread is mutating or like physically changing 20 00:00:53.240 --> 00:00:56.039 that exact same data right out from under you. Yeah, 21 00:00:56.119 --> 00:00:59.359 and it's the root cause of so many unpredictable bugs. 22 00:01:00.200 --> 00:01:03.079 Today's deep dive is all about stopping that page flipping. 23 00:01:03.600 --> 00:01:07.840 We're exploring the surprisingly practical world of functional programming, but 24 00:01:08.599 --> 00:01:12.120 we're doing it inside language. Most people associate strictly with 25 00:01:12.319 --> 00:01:16.280 object oriented programming, which is C shark, right, and we're 26 00:01:16.319 --> 00:01:19.840 pulling our insights from Enrico Banana's book Functional Programming in 27 00:01:19.920 --> 00:01:23.359 C Sharp. The mission here is to basically act as 28 00:01:23.359 --> 00:01:26.359 a shortcut for you, because you absolutely do not need 29 00:01:26.359 --> 00:01:28.959 a PhD in mathematics to use these concepts. 30 00:01:29.120 --> 00:01:30.159 No, you really don't. 31 00:01:30.319 --> 00:01:32.519 We're going to look at how functional techniques can you know, 32 00:01:32.640 --> 00:01:37.159 drastically reduce bugs, handle concurrency almost effortlessly, and just make 33 00:01:37.200 --> 00:01:38.879 your code based so much more readable. 34 00:01:39.040 --> 00:01:41.560 Yeah, and I think that's important because functional programming often 35 00:01:41.560 --> 00:01:45.799 gets this unfair reputation for being overly academic. 36 00:01:46.079 --> 00:01:49.079 Yeah, totally, like it's just Ivory Tower stuff exactly. 37 00:01:49.439 --> 00:01:52.280 But when you actually apply it to real world line 38 00:01:52.319 --> 00:01:55.359 of business applications in C sharp, it becomes this highly 39 00:01:55.480 --> 00:01:59.319 pragmatic tool set. It really boils down to changing two 40 00:01:59.519 --> 00:02:02.079 ingrained like how we treat our data and how we 41 00:02:02.120 --> 00:02:02.959 treat our behavior. 42 00:02:03.200 --> 00:02:05.760 Well, let's start with behavior then, because that ties right 43 00:02:05.799 --> 00:02:07.719 into how we manage the flow of an application. 44 00:02:08.639 --> 00:02:09.360 In c sharp. 45 00:02:09.759 --> 00:02:14.560 Functions aren't just invisible blocks of code anymore. They are 46 00:02:14.560 --> 00:02:17.319 what we call first class values, which means you can 47 00:02:17.360 --> 00:02:20.240 take a function, assign it to a variable, or pass 48 00:02:20.280 --> 00:02:23.199 it as an argument into another function, just like you 49 00:02:23.199 --> 00:02:26.120 would with a regular string or an integer. 50 00:02:26.400 --> 00:02:29.240 Yeah, and we use delegates and lambed expressions to do this, 51 00:02:29.639 --> 00:02:32.280 and treating functions as data. It unlocks one of the 52 00:02:32.319 --> 00:02:34.319 most foundational tools in functional. 53 00:02:33.960 --> 00:02:35.400 Programming, a higher order function. 54 00:02:35.560 --> 00:02:38.439 Exactly the higher order function people usually just shorten it 55 00:02:38.479 --> 00:02:42.199 to HOF. HOF is simply any function that either takes 56 00:02:42.240 --> 00:02:46.400 another function as an input parameter or returns a function 57 00:02:46.560 --> 00:02:47.360 as its output. 58 00:02:47.639 --> 00:02:50.840 Right, And thinking about this in real world terms, using 59 00:02:50.879 --> 00:02:54.520 a HOF feels a lot like hiring a subcontractor oh 60 00:02:54.560 --> 00:02:58.039 I like that? How so Well, take the lanq wear method, 61 00:02:58.080 --> 00:02:59.599 which we use to filter lists all the time in 62 00:02:59.639 --> 00:03:02.800 C sharp. In this scenario, where's the manager. It handles 63 00:03:02.800 --> 00:03:05.439 all the tedious border plate stuff, setting up a loop, 64 00:03:05.599 --> 00:03:08.479 managing the index. You know, all the mechanical parts. 65 00:03:08.360 --> 00:03:10.159 Right, the stuff you don't want to write over and 66 00:03:10.199 --> 00:03:11.000 over exactly. 67 00:03:11.199 --> 00:03:13.439 Yeah, But the manager doesn't actually know what you're looking for, 68 00:03:13.800 --> 00:03:18.039 so it subcontracts the decision making logic asking like should 69 00:03:18.039 --> 00:03:21.759 I keep this specific item? It delegates that to the 70 00:03:21.800 --> 00:03:23.080 function that you pass into it. 71 00:03:23.159 --> 00:03:25.879 That is a perfect analogy. The division of labor is 72 00:03:25.960 --> 00:03:29.800 so clear. The hof handles the mechanics and you supply 73 00:03:29.879 --> 00:03:31.199 the unique business logic. 74 00:03:31.360 --> 00:03:31.560 Yeah. 75 00:03:31.879 --> 00:03:36.280 Another incredibly practical application for this is encapsulating set up 76 00:03:36.479 --> 00:03:41.680 and tear down logic. Think about how often you interact 77 00:03:41.680 --> 00:03:44.120 with the database. Oh, all the time, right, and you 78 00:03:44.159 --> 00:03:46.800 always have to do the same dance. You acquire a connection, 79 00:03:47.120 --> 00:03:49.960 open it, do your work, close it, and then dispose 80 00:03:50.000 --> 00:03:50.719 of the resource. 81 00:03:50.840 --> 00:03:54.000 Oh man, the endless using blocks You end up copying 82 00:03:54.000 --> 00:03:56.840 and pasting those same five lines of code across like 83 00:03:56.960 --> 00:03:58.159 fifty different repositors. 84 00:03:58.319 --> 00:04:00.680 So repetitive. But with a higher order function, you can 85 00:04:00.759 --> 00:04:04.599 just write a custom using function one single time. Oh right. 86 00:04:04.719 --> 00:04:08.000 That one function handles opening the connection and disposing of 87 00:04:08.039 --> 00:04:10.800 it in a finally block, and you just pass it 88 00:04:10.840 --> 00:04:13.240 a function that represents the specific query you want to 89 00:04:13.280 --> 00:04:13.960 run in the middle. 90 00:04:14.120 --> 00:04:18.560 That's brilliant. It completely eliminates all that boilerplate duplication exactly. 91 00:04:18.759 --> 00:04:21.959 So Okay, the manager handles the subcontractors, the code gets cleaner. 92 00:04:22.439 --> 00:04:26.240 But even the best manager can't fix a job site 93 00:04:26.399 --> 00:04:29.600 if the blueprints keep magically changing while the crew is 94 00:04:29.639 --> 00:04:30.120 reading them. 95 00:04:30.240 --> 00:04:32.360 Right back to the page flipping problem. 96 00:04:32.000 --> 00:04:34.519 Exactly which brings us to this second habit. 97 00:04:34.600 --> 00:04:35.399 We have to change. 98 00:04:35.519 --> 00:04:38.600 We have to avoid state mutation, right. 99 00:04:38.639 --> 00:04:42.560 And mutating state simply means changing and existing value in 100 00:04:42.600 --> 00:04:45.439 place and memory. For instance, if you have a list 101 00:04:45.480 --> 00:04:48.759 of numbers in C sharp and you call list sort, 102 00:04:49.240 --> 00:04:53.199 the framework physically rearranges those items in your computer's memory. 103 00:04:53.279 --> 00:04:55.360 Right, it's a destructive update. The original order is just 104 00:04:55.399 --> 00:04:55.959 gone forever. 105 00:04:56.199 --> 00:04:58.800 But if you use LA and Q's order by method, 106 00:04:59.240 --> 00:05:02.000 it behaves complete lely differently. It doesn't touch your original list. 107 00:05:02.079 --> 00:05:04.879 It reads it and then creates a brand new list, 108 00:05:04.959 --> 00:05:07.800 a new view of the data that happens to be sorted. 109 00:05:07.600 --> 00:05:09.639 Leaving the original completely intact. 110 00:05:09.800 --> 00:05:13.480 Exactly, And that distinction might seem minor, but it is 111 00:05:13.560 --> 00:05:17.680 exactly what saves you from the concurrency disaster. Buanano's book 112 00:05:17.759 --> 00:05:19.560 has this terrifying example of this. 113 00:05:19.639 --> 00:05:21.120 Oh yeah, the math there one, right. 114 00:05:21.639 --> 00:05:25.439 Imagine a background task Task one. It's trying to calculate 115 00:05:25.480 --> 00:05:28.120 the sum of a massive list of numbers running from 116 00:05:28.199 --> 00:05:30.920 positive ten thousand all the way down to negative ten thousand. 117 00:05:31.000 --> 00:05:33.560 Okay, so logically, if you add all those up, the 118 00:05:33.639 --> 00:05:35.639 sum should perfectly balance out to zero. 119 00:05:35.800 --> 00:05:39.360 It should, But imagine that at the exact same millisecond. 120 00:05:39.680 --> 00:05:42.560 Task two is concurrently running on a different thread, and 121 00:05:42.600 --> 00:05:45.560 it calls list sort on that exact same list. 122 00:05:45.600 --> 00:05:49.399 Oh no, because list sort mutates the list in place. 123 00:05:49.759 --> 00:05:52.519 Task one is trying to do math, while task two 124 00:05:52.639 --> 00:05:54.879 is aggressively moving the numbers around exactly. 125 00:05:54.959 --> 00:05:57.199 Task one might read the number five thousand, and then 126 00:05:57.240 --> 00:05:59.560 task two moves that five thousand further down the. 127 00:05:59.480 --> 00:06:01.759 List, and this one just reads it a second time. 128 00:06:01.879 --> 00:06:04.240 Right, so the result isn't zero, the book points out, 129 00:06:04.279 --> 00:06:08.319 You get these bizarre, totally unpredictable results, like returning a 130 00:06:08.360 --> 00:06:11.639 sum of nine, three hundred thirty nine and seventy. 131 00:06:11.800 --> 00:06:12.480 That is wild. 132 00:06:12.759 --> 00:06:15.519 And this is why concurrency and traditional imperative programming is 133 00:06:15.560 --> 00:06:18.360 so notoriously difficult. You have to introduce complex locks, You 134 00:06:18.360 --> 00:06:20.360 have to freeze the entire list just to read it, 135 00:06:20.360 --> 00:06:21.800 which just destroys your performance. 136 00:06:22.120 --> 00:06:26.360 But if you embrace immutable data, where sorting creates a 137 00:06:26.399 --> 00:06:30.600 new list instead of destroying the old one, concurrent reads 138 00:06:31.000 --> 00:06:33.240 don't cause any inconsistencies whatsoever. 139 00:06:33.480 --> 00:06:37.279 Right, you get parallelization essentially for free, because nobody is 140 00:06:37.319 --> 00:06:39.439 flipping the pages of the book you are trying to read. 141 00:06:39.560 --> 00:06:42.600 I mean, if you've ever stared at a massive, tangled 142 00:06:42.680 --> 00:06:46.079 legacy code base and felt sheer panic at the thought 143 00:06:46.079 --> 00:06:49.959 of making it thread safe. Realizing that avoiding mutation gives 144 00:06:49.959 --> 00:06:53.240 you a free pass to parallel execution is just a 145 00:06:53.319 --> 00:06:54.639 massive light bulb moment. 146 00:06:54.800 --> 00:06:55.639 It really is. 147 00:06:55.959 --> 00:06:59.360 And taking this idea of avoiding mutation to its logical 148 00:06:59.399 --> 00:07:02.680 extreme brings us to the concept of the pure function. 149 00:07:03.360 --> 00:07:06.439 Yes, the pursuit of purity is central here. A pure 150 00:07:06.480 --> 00:07:10.160 function closely resembles a mathematical equation. It operates under two 151 00:07:10.360 --> 00:07:14.720 very strict rules. First, its output depends entirely and exclusively 152 00:07:14.759 --> 00:07:18.160 on its input arguments okay, And second, it causes absolutely 153 00:07:18.160 --> 00:07:18.920 no side effects. 154 00:07:19.040 --> 00:07:21.560 Now, side effects is a really broad category, right, We 155 00:07:21.600 --> 00:07:25.240 aren't just talking about mutating global variables. In functional programming, 156 00:07:25.360 --> 00:07:27.759 throwing an exception is considered a side effect. Yes, it 157 00:07:27.839 --> 00:07:31.120 is performing any kind of IO like printing to the console, 158 00:07:31.639 --> 00:07:34.439 querying a database, or even just checking the system clock. 159 00:07:34.600 --> 00:07:36.720 Those are all side effects. 160 00:07:36.319 --> 00:07:38.800 Right, And people always ask why is checking the clock 161 00:07:38.839 --> 00:07:41.560 a side effect? It's because anytime you rely on the 162 00:07:41.600 --> 00:07:46.680 external physical world, your function loses its determinism. Oh, if 163 00:07:46.680 --> 00:07:49.240 a function asks the system for the current time to 164 00:07:49.480 --> 00:07:52.759 validate a token, it will return a different result tomorrow 165 00:07:52.800 --> 00:07:55.040 than it did today, even if you pass in the 166 00:07:55.079 --> 00:07:56.319 exact same token. 167 00:07:56.199 --> 00:07:59.480 Right, whereas a truly pure function guarantees the exact same 168 00:07:59.519 --> 00:08:03.240 output every single time until the end of the universe exactly. 169 00:08:03.720 --> 00:08:07.600 The book contrasts two string manipulation functions to show why 170 00:08:07.639 --> 00:08:10.439 this matters for scaling up. One is a pure function 171 00:08:10.519 --> 00:08:12.720 called toe sentence case. It just takes a string and 172 00:08:12.759 --> 00:08:15.759 formats the capitalization super simple. The other is an impure 173 00:08:15.800 --> 00:08:18.920 function called pre pend counter. It takes a string, but 174 00:08:19.000 --> 00:08:21.639 it also reaches outside itself to use the plus plus 175 00:08:21.720 --> 00:08:25.319 operator to increment a shared global counter variable, so it 176 00:08:25.360 --> 00:08:26.560 can number the strings. 177 00:08:26.920 --> 00:08:29.360 And if you try to run that impure pre pen 178 00:08:29.480 --> 00:08:34.000 counter in parallel across a million strings, it falls apart 179 00:08:34.279 --> 00:08:37.879 because at the CPU level, plus is actually multiple steps 180 00:08:37.919 --> 00:08:40.159 read the value, add one, write it back. 181 00:08:40.240 --> 00:08:43.559 It's not atomic, right, Multiple threads read the shared counter 182 00:08:43.600 --> 00:08:45.960 at the exact same millisecond, they all add one to 183 00:08:46.000 --> 00:08:48.960 the same base number and write it back. They trample each. 184 00:08:48.799 --> 00:08:50.759 Other, so you lose thousands of updates. 185 00:08:50.879 --> 00:08:53.919 Yeah, your final count will be completely wrong. But the 186 00:08:53.919 --> 00:08:56.440 pure to sentence case function, you can spread that across 187 00:08:56.480 --> 00:08:58.639 one hundred different CPU cores instantly. 188 00:08:58.720 --> 00:09:00.960 Because it doesn't rely on anything else side itself, it 189 00:09:01.039 --> 00:09:05.600 is completely isolated, which means it's thread safe by default exactly. 190 00:09:06.159 --> 00:09:09.360 And that complete isolation is why pure functions are an 191 00:09:09.399 --> 00:09:12.519 absolute dream to unit test. You don't need to configure 192 00:09:12.639 --> 00:09:16.200 dependency injection or complex mock objects. You just feed it 193 00:09:16.240 --> 00:09:18.320 an input and assert the output. 194 00:09:18.120 --> 00:09:21.000 Whereas testing in pure io is usually a nightmare. To 195 00:09:21.080 --> 00:09:23.519 test a service that happens to check the time, developers 196 00:09:23.600 --> 00:09:28.080 usually resort to creating these totally hollow header interfaces. You 197 00:09:28.159 --> 00:09:30.879 end up creating an I date time service and wiring 198 00:09:30.879 --> 00:09:33.759 it up everywhere solely so you can inject a fake 199 00:09:34.120 --> 00:09:37.759 frozen clock into your unit test to mock DateTime dot 200 00:09:37.840 --> 00:09:38.720 ut as nail. 201 00:09:39.000 --> 00:09:42.039 It hadds so many layers of boilerplate just to test 202 00:09:42.080 --> 00:09:46.120 a simple date validation. The functional approach solves this by 203 00:09:46.159 --> 00:09:48.120 pushing the pure boundary outwards. 204 00:09:48.440 --> 00:09:49.480 What do you mean by outwards? 205 00:09:49.600 --> 00:09:52.799 Instead of injecting a massive mocked interface that goes out 206 00:09:52.799 --> 00:09:55.679 and gets the date, just inject a hard coded daytime 207 00:09:55.759 --> 00:09:58.440 value directly into your validator as an argument. 208 00:09:58.679 --> 00:10:01.320 Oh, so the val itself stays. 209 00:10:01.080 --> 00:10:04.120 Pure exactly, Or if you need to validate against a 210 00:10:04.159 --> 00:10:07.120 list of valid bank routing numbers from a database. Don't 211 00:10:07.120 --> 00:10:10.399 inject an entire I repository interface. Just in ject a 212 00:10:10.440 --> 00:10:13.240 simple function like a delegate returning a list of strings 213 00:10:13.240 --> 00:10:14.519 that the validator can invoke. 214 00:10:14.720 --> 00:10:17.440 Okay, wait, I'm trying to picture an application built entirely 215 00:10:17.480 --> 00:10:19.759 like this, a program with absolutely no IO. 216 00:10:19.960 --> 00:10:21.320 It's basically just a space heater. 217 00:10:21.440 --> 00:10:24.480 A space heater, yeah, I mean it consumes electricity, gets 218 00:10:24.480 --> 00:10:27.399 a CPU hot, and does absolutely nothing useful. We have 219 00:10:27.440 --> 00:10:28.799 to have side effects, right, we have to save to 220 00:10:28.879 --> 00:10:30.559 databases and display things on screens. 221 00:10:30.759 --> 00:10:34.320 That is a very valid reality check, and functional programming 222 00:10:34.360 --> 00:10:38.960 absolutely acknowledges that the goal was never to eliminate IO entirely. 223 00:10:39.399 --> 00:10:40.519 It is to isolate it. 224 00:10:40.840 --> 00:10:41.200 Okay. 225 00:10:41.360 --> 00:10:45.120 The book uses a document converter application called pandock to 226 00:10:45.159 --> 00:10:49.720 illustrate this architecture. You isolate the pure computational core, the 227 00:10:49.879 --> 00:10:54.200 complex logic of parsing, markup, translating, syntax, formatting, the layout 228 00:10:54.240 --> 00:10:56.960 that is all pure, and then you wrap that core 229 00:10:57.159 --> 00:11:00.840 in an impure IO shell. The shell handle reading the 230 00:11:00.879 --> 00:11:03.360 original file from the hard drive and writing the final 231 00:11:03.399 --> 00:11:04.799 PDF back to the disc. 232 00:11:04.919 --> 00:11:07.840 Oh I see, so you actively push the MESSI impurity 233 00:11:07.879 --> 00:11:10.399 to the very edges of your application exactly. 234 00:11:10.440 --> 00:11:12.759 You keep the messy real world on the outside and 235 00:11:12.799 --> 00:11:15.200 your core business logic pure on the inside. 236 00:11:15.480 --> 00:11:18.840 But that raises a major question about error handling. If 237 00:11:18.879 --> 00:11:21.879 our pure functions aren't allowed to throw exceptions, how do 238 00:11:21.919 --> 00:11:23.159 we handle bad data? 239 00:11:23.240 --> 00:11:23.480 Right? 240 00:11:23.639 --> 00:11:26.159 Like, if someone passes my pure function and negative age 241 00:11:26.279 --> 00:11:28.360 and I can't throw an argument exception, what are we 242 00:11:28.360 --> 00:11:28.879 supposed to do? 243 00:11:29.240 --> 00:11:31.480 This brings us to the concept of making our function 244 00:11:31.600 --> 00:11:35.799 signatures honest. A signature, its name, inputs, and return type 245 00:11:35.919 --> 00:11:37.799 is essentially a contract, right. 246 00:11:38.120 --> 00:11:40.759 It tells the caller what inputs it requires and what 247 00:11:40.840 --> 00:11:42.399 output it guarantees. 248 00:11:42.120 --> 00:11:45.559 Exactly, and the book highlights how easily we lie in 249 00:11:45.600 --> 00:11:48.679 these contracts. There's an example of a dishonest signature, a 250 00:11:48.759 --> 00:11:52.480 function named calculator risk profile that takes the standard integer 251 00:11:52.600 --> 00:11:53.679 for the age parameter. 252 00:11:53.919 --> 00:11:54.240 Okay. 253 00:11:54.360 --> 00:11:56.639 The signature promises that if you give it any integer, 254 00:11:57.000 --> 00:12:01.080 even negative one thousand, it will successfully return a risk profile. 255 00:12:01.279 --> 00:12:04.159 But inside the body it checks if the age is negative. 256 00:12:04.200 --> 00:12:06.440 If it is, it throws an argument exception and halts 257 00:12:06.480 --> 00:12:07.000 the program. 258 00:12:07.159 --> 00:12:11.000 It's a completely dishonest contract. The caller reads the signature 259 00:12:11.399 --> 00:12:14.480 assumes they're safe providing any integer, and then at runtime 260 00:12:14.519 --> 00:12:15.919 the app violently crashes. 261 00:12:16.080 --> 00:12:19.799 Exactly functional programming actively avoids hidden traps like this. 262 00:12:20.120 --> 00:12:23.399 So how do we fix a dishonest signature without throwing 263 00:12:23.440 --> 00:12:26.440 an exception? We use a pattern called a smart constructor. 264 00:12:26.919 --> 00:12:30.159 Instead of accepting a raw integer for age, we define 265 00:12:30.200 --> 00:12:33.919 a custom immutable age type and we write a smart 266 00:12:33.960 --> 00:12:37.799 constructor method like age two seat. This runs the validation 267 00:12:37.960 --> 00:12:40.960 logic before the age object is ever allowed to be created. 268 00:12:41.159 --> 00:12:46.279 By enforcing that validation upfront, you make invalid states unrepresentable 269 00:12:46.320 --> 00:12:50.399 in your system. Once your code holds an instantiated age object, 270 00:12:50.759 --> 00:12:54.039 you know for a fact it contains a valid positive age. 271 00:12:54.320 --> 00:12:58.240 So your calculat risk profile function changes its signature to 272 00:12:58.320 --> 00:13:00.480 require an age type instead of integer. 273 00:13:00.759 --> 00:13:04.480 Yep, the signature becomes completely honest and the function never 274 00:13:04.519 --> 00:13:07.480 has to worry about throwing an exception for negative numbers. Ever. 275 00:13:07.519 --> 00:13:10.320 Again, that makes perfect sense for a validation. But what 276 00:13:10.440 --> 00:13:14.480 about retrieving missing data? Because the standard dot net collections 277 00:13:14.559 --> 00:13:18.159 drive me a little crazy with their inconsistency here how so, Well, 278 00:13:18.200 --> 00:13:20.320 if I use a name value collection and ask for 279 00:13:20.320 --> 00:13:24.480 a dictionary key that doesn't exist like green, it quietly returns. 280 00:13:24.080 --> 00:13:25.120 A null value. 281 00:13:25.320 --> 00:13:27.559 But if I use a standard dictionary and ask for blue, 282 00:13:27.840 --> 00:13:29.320 it throws a keynot found exception. 283 00:13:29.440 --> 00:13:33.320 Oh yeah. Under the functional paradigm, both those outcomes, returning 284 00:13:33.360 --> 00:13:37.240 a silent null or throwing a loud exception are considered dishonest. 285 00:13:37.879 --> 00:13:39.879 If a function goes looking for a value and might 286 00:13:39.879 --> 00:13:43.120 not find it, its signature needs to explicitly declare that 287 00:13:43.159 --> 00:13:46.480 failure is a distinct possibility. This is where we introduce 288 00:13:46.559 --> 00:13:47.480 the option type. 289 00:13:47.639 --> 00:13:50.799 The option type you might hear it called maybe in 290 00:13:50.840 --> 00:13:55.200 other languages. It essentially models data that might be absent yes. 291 00:13:55.399 --> 00:13:58.919 It has two possible states, some and none. 292 00:13:59.360 --> 00:14:02.600 I like to vision the option type as a cardboard 293 00:14:02.639 --> 00:14:06.440 shipping box. You order a new gadget online. When the 294 00:14:06.480 --> 00:14:09.720 delivery arrives, the box either contains the gadget you wanted. 295 00:14:09.919 --> 00:14:12.720 That's the sum state, or there was a warehouse mix 296 00:14:12.799 --> 00:14:15.919 up and the box is empty, which represents the nun state. 297 00:14:16.120 --> 00:14:19.840 That's a great visualization, but crucially, either way, the delivery 298 00:14:19.919 --> 00:14:23.039 driver still handed you a physical box. You can safely 299 00:14:23.080 --> 00:14:25.639 hold it, pass it to another department, and write code 300 00:14:25.639 --> 00:14:27.720 to handle the box without your program crashing. 301 00:14:27.879 --> 00:14:31.120 Exactly, instead of returning null, which is just a ticking 302 00:14:31.159 --> 00:14:34.039 time bomb that causes a null reference exception. The second 303 00:14:34.039 --> 00:14:36.480 you try to access it you return an option. It 304 00:14:36.519 --> 00:14:39.519 explicitly communicates to the developer the statu might be absent. 305 00:14:39.759 --> 00:14:42.080 You are forced to handle the empty box scenario. 306 00:14:42.120 --> 00:14:42.679 Hang on, though. 307 00:14:43.320 --> 00:14:46.960 Let's say a business requirement changes marketing decides that the 308 00:14:47.000 --> 00:14:50.360 first name field on a massive newsletter sign up form 309 00:14:50.879 --> 00:14:53.759 should now be optional. If I go into my C 310 00:14:53.879 --> 00:14:56.720 sharp domain model and change the first name property from 311 00:14:56.759 --> 00:14:59.840 a regular string to an option string, every single piece 312 00:14:59.879 --> 00:15:02.960 of code in my application that touch's first name is. 313 00:15:02.879 --> 00:15:05.399 Going to break immediately. It won't even compile. 314 00:15:05.960 --> 00:15:08.200 How is breaking the bild a good thing? 315 00:15:08.399 --> 00:15:12.360 It is actually a fantastic thing, because you're trading silent, 316 00:15:12.600 --> 00:15:17.399 unpredictable run time crashes for loud immediate compile time errors. 317 00:15:17.799 --> 00:15:20.399 Think about the alternative. If you just allowed that string 318 00:15:20.480 --> 00:15:23.000 to be null, your code would compile perfectly fine, but 319 00:15:23.039 --> 00:15:25.440 it would crash in production a week later the very 320 00:15:25.440 --> 00:15:28.279 first time user didn't enter their name and a downstream 321 00:15:28.320 --> 00:15:30.960 system tried to call to Hupper on it ah right. 322 00:15:31.080 --> 00:15:33.559 By changing the signature to an option, the compiler becomes 323 00:15:33.600 --> 00:15:36.639 your personal assistant. It flags every single place in your 324 00:15:36.679 --> 00:15:39.679 massive codebase that needs to be updated to acknowledge this 325 00:15:39.879 --> 00:15:41.240 new optional reality. 326 00:15:41.480 --> 00:15:43.720 Okay, I see the safety in that. Yeah, but it 327 00:15:43.759 --> 00:15:45.679 brings up a huge logistical headache. 328 00:15:45.720 --> 00:15:46.159 What's that? 329 00:15:46.639 --> 00:15:47.919 If we safely pack our. 330 00:15:47.799 --> 00:15:51.720 Missing data into these option shipping boxes, how do we 331 00:15:51.759 --> 00:15:54.039 actually do any work on the data inside the box. 332 00:15:54.679 --> 00:15:57.559 Like if I have a pure function that expects a 333 00:15:57.600 --> 00:16:00.720 regular string, but my database returned in an option string, 334 00:16:01.200 --> 00:16:03.759 I can't just pass the box to the function. Do 335 00:16:03.879 --> 00:16:06.720 I have to write an if statement every single time 336 00:16:06.759 --> 00:16:09.159 to check if the box is empty, unpack it, run 337 00:16:09.200 --> 00:16:12.519 the function, and repack it. That sounds exhausting it. 338 00:16:12.480 --> 00:16:14.559 Would be, but you don't have to do that manually. 339 00:16:15.120 --> 00:16:18.279 That is exactly where we introduce the core functional design 340 00:16:18.360 --> 00:16:22.000 patterns functors and monads, which are operated by the map 341 00:16:22.039 --> 00:16:23.120 and bind functions. 342 00:16:23.679 --> 00:16:27.120 I know, the terms functors and monads sound incredibly intimidating. 343 00:16:27.120 --> 00:16:29.240 They sound like advanced category theory. 344 00:16:29.320 --> 00:16:32.399 They do carry a lot of academic baggage, but stripped 345 00:16:32.399 --> 00:16:34.799 down to their basics, they are just patterns for structures 346 00:16:34.840 --> 00:16:37.159 you already use every day. An option or an I 347 00:16:37.279 --> 00:16:41.799 innumerable list. Those are containers. They represent values existing at 348 00:16:41.799 --> 00:16:43.360 an elevated level of abstraction. 349 00:16:43.759 --> 00:16:46.759 So let's demystify the functor first, which relies on a 350 00:16:46.759 --> 00:16:49.919 function called map. The map function reaches into your container, 351 00:16:50.200 --> 00:16:53.559 takes the inner value out, applies your regular business logic 352 00:16:53.559 --> 00:16:56.600 function to it, and then reboxes the new result back 353 00:16:56.600 --> 00:16:59.440 into a new container, and you never have to write 354 00:16:59.480 --> 00:17:02.600 an if statement to check if the value is actually there. 355 00:17:03.200 --> 00:17:05.279 If the option box happens to be in the nun state. 356 00:17:05.400 --> 00:17:07.960 If it's empty, Map is smart enough to just bypass 357 00:17:08.000 --> 00:17:11.720 your function entirely and return a new none. If it 358 00:17:11.759 --> 00:17:14.680 is in the sum state, it applies the function and 359 00:17:14.759 --> 00:17:18.440 wraps the result in a new sum. It completely abstracts 360 00:17:18.440 --> 00:17:21.240 away the boilerplate of checking for the absence of data. 361 00:17:21.920 --> 00:17:24.799 The book has an amazing analogy to explain map. Think 362 00:17:24.799 --> 00:17:28.119 of your aunt who absolutely loves baking apple pies. 363 00:17:28.279 --> 00:17:29.359 Okay, I love this one. 364 00:17:29.519 --> 00:17:30.119 You leave a. 365 00:17:30.079 --> 00:17:33.880 Basket of apples on her front porch. The basket itself 366 00:17:33.920 --> 00:17:36.920 is the option container. The apples are the concrete value 367 00:17:36.920 --> 00:17:41.599 inside her baking skills represent your business logic function. You 368 00:17:41.720 --> 00:17:45.039 leave the basket, She takes the apples out, bakes a pie, 369 00:17:45.279 --> 00:17:48.119 and puts the pie back into the basket. What started 370 00:17:48.119 --> 00:17:50.319 as an option of apples is now an option of pie. 371 00:17:50.559 --> 00:17:52.240 And how does she handle an empty basket? 372 00:17:52.279 --> 00:17:54.799 That's the brilliance of map. If you leave an empty 373 00:17:54.799 --> 00:17:58.559 basket of bandit yeah, yeah, none, she doesn't freak out, 374 00:17:58.759 --> 00:18:00.920 She doesn't throw a null reference exception or call you 375 00:18:00.960 --> 00:18:02.960 in a panic. She just smiles and leaves the empty 376 00:18:03.000 --> 00:18:04.880 basket right there on the board exactly. You don't have 377 00:18:04.920 --> 00:18:06.759 to explain to her what to do with empty space. 378 00:18:07.319 --> 00:18:10.319 The map process handles the empty state automatically. 379 00:18:10.920 --> 00:18:14.759 That analogy perfectly captures how a functor works, but we 380 00:18:14.880 --> 00:18:18.400 inevitably run into a more complex scenario. What happens if 381 00:18:18.440 --> 00:18:21.839 the function you are applying also returns an option container? 382 00:18:22.000 --> 00:18:22.680 Oh? I see? 383 00:18:23.000 --> 00:18:25.039 Like if I have an option of a strength from 384 00:18:25.039 --> 00:18:27.759 a database and I pass it to a parsing function 385 00:18:27.880 --> 00:18:30.559 that tries to turn it into an integer, that parsing 386 00:18:30.559 --> 00:18:34.119 function might fail, so it returns an option of an integer, right, 387 00:18:34.200 --> 00:18:36.640 and then I pass that integer to our smart constructor 388 00:18:36.640 --> 00:18:38.839 for age, which also returns an option of age. 389 00:18:38.839 --> 00:18:42.079 Precisely, if you use the standard map function to string 390 00:18:42.119 --> 00:18:44.559 those operations together, you have a structural problem. 391 00:18:44.799 --> 00:18:47.319 Let me think about how the generic types would stack up. 392 00:18:48.359 --> 00:18:51.279 Map always puts the result in a new box. So 393 00:18:51.319 --> 00:18:53.480 if my function returns an option age and Map puts 394 00:18:53.480 --> 00:18:55.599 that result in a box, I end up with an 395 00:18:55.599 --> 00:18:59.319 option containing option containing an age. Yeah, it's like Russian 396 00:18:59.359 --> 00:19:03.359 nesting dolls of day option age. That sounds impossible to 397 00:19:03.400 --> 00:19:03.680 work with. 398 00:19:03.799 --> 00:19:07.319 It is very clunky, and that exact problem nested containers 399 00:19:07.359 --> 00:19:10.279 is where monads and the bind function come to the rescue. 400 00:19:10.440 --> 00:19:11.839 Okay, so what does bind do. 401 00:19:12.359 --> 00:19:16.519