WEBVTT 1 00:00:00.160 --> 00:00:02.960 So how often do you actually think about the invisible 2 00:00:03.040 --> 00:00:07.839 architecture of the Internet when you do something really simple, 3 00:00:08.279 --> 00:00:09.439 like say a Google search. 4 00:00:10.039 --> 00:00:12.359 I mean probably never, right, You just want your answer 5 00:00:12.480 --> 00:00:13.000 right exactly. 6 00:00:13.080 --> 00:00:16.239 You type in a query, hit enter, and boom, billions 7 00:00:16.280 --> 00:00:18.239 of records are just sifted through to hand you a 8 00:00:18.280 --> 00:00:21.640 result in literally milliseconds. We treat it like magic. 9 00:00:21.719 --> 00:00:24.519 Oh absolutely, But you know, peaking under the hood reveals 10 00:00:24.519 --> 00:00:26.079 something entirely unexpected. 11 00:00:26.239 --> 00:00:29.440 Yeah, you won't just find like miles of fiber optic 12 00:00:29.440 --> 00:00:33.280 cables or massive server farms. You actually find this intense, 13 00:00:33.560 --> 00:00:36.560 unresolved mathematical debate from the nineteen. 14 00:00:36.280 --> 00:00:39.679 Thirties and the remnants of a totally failed nineteen eighties 15 00:00:39.719 --> 00:00:41.039 software revolution. 16 00:00:40.719 --> 00:00:44.079 Too, which is wild and well. It all points to 17 00:00:44.119 --> 00:00:47.479 a completely alien philosophy regarding how computers should solve problems 18 00:00:47.520 --> 00:00:48.200 in the first place. 19 00:00:48.359 --> 00:00:50.520 It really is a fundamental shift in logic. I mean, 20 00:00:50.600 --> 00:00:53.359 anybody who has written even a few lines of say 21 00:00:53.439 --> 00:00:58.320 Python or JavaScript, they intuitively understand computers as machines that 22 00:00:58.439 --> 00:01:01.039 just follow sequential instructions. 23 00:01:00.240 --> 00:01:02.560 Like step one, do this, step two, check that. 24 00:01:02.799 --> 00:01:05.760 Exactly, step three, update this counter. But there is an 25 00:01:05.879 --> 00:01:09.519 entire parallel universe of programming that completely abandons that step 26 00:01:09.519 --> 00:01:11.879 by step logic, basically rips the clock out of the 27 00:01:11.879 --> 00:01:12.799 computer entirely. 28 00:01:13.000 --> 00:01:15.799 And we are dissecting that universe today through our deep 29 00:01:15.840 --> 00:01:20.159 dive into Greg Michaelson's book An Introduction to Functional Programming 30 00:01:20.159 --> 00:01:21.079 through Lambda. 31 00:01:20.760 --> 00:01:23.799 Calculus, a fantastic albeit heavy. 32 00:01:23.680 --> 00:01:27.879 Read, oh definitely heavy. We're specifically looking at his foundational 33 00:01:27.959 --> 00:01:31.200 chapters and that rather candid twenty eleven Prephecy wrote, and 34 00:01:31.319 --> 00:01:33.200 you know, the objective here isn't just to learn a 35 00:01:33.200 --> 00:01:34.040 new coding language. 36 00:01:34.120 --> 00:01:35.760 No, no, it's way bigger than that, right. 37 00:01:35.680 --> 00:01:39.560 It's to understand what functional programming actually is mechanically, like, 38 00:01:40.040 --> 00:01:43.719 why this incredibly dense, seventy five year old math concept 39 00:01:44.120 --> 00:01:46.599 breaks our standard rules of computing, and. 40 00:01:46.480 --> 00:01:49.159 How it quietly became the load bearing pillar for the 41 00:01:49.159 --> 00:01:51.280 biggest distributed systems on the planet. 42 00:01:51.400 --> 00:01:54.040 So to appreciate this functional approach, we really have to 43 00:01:54.079 --> 00:01:58.120 isolate the underlying flaw in how we normally write software. 44 00:01:58.200 --> 00:02:01.640 Yeah, we do so. The most commercial code is written 45 00:02:01.719 --> 00:02:05.799 in what we call imperative languages. So thinks ce Java, Python, 46 00:02:06.000 --> 00:02:08.960 usual suspects, right, and they are built on this concept 47 00:02:09.000 --> 00:02:13.080 of mutating state. You issue an imperative command to change 48 00:02:13.120 --> 00:02:13.919 the value of a. 49 00:02:13.919 --> 00:02:16.319 Variable, like giving the computer in order. 50 00:02:16.520 --> 00:02:19.879 Exactly, you tell the system, hey, X is currently five, 51 00:02:19.960 --> 00:02:22.319 but now I command you to make x equal to. 52 00:02:22.319 --> 00:02:25.400 Six, which I mean that seems entirely logical to me. 53 00:02:25.800 --> 00:02:28.599 We are commanding the machine to update its memory. 54 00:02:28.680 --> 00:02:31.080 It does seem logical, well, until you try to do 55 00:02:31.120 --> 00:02:32.199 a million things at once. 56 00:02:32.360 --> 00:02:34.520 Aw the scale issue. 57 00:02:34.639 --> 00:02:38.759 Right. Because imperative programming is entirely reliant on state mutation, 58 00:02:39.280 --> 00:02:42.599 it creates this terrifying vulnerability known as a side effect. 59 00:02:42.759 --> 00:02:45.439 Okay, let's unpack this. Yeah, what exactly does a side 60 00:02:45.439 --> 00:02:46.520 effect look like in action? 61 00:02:46.960 --> 00:02:50.919 Well, imagine you have a variable tracking a user's bank balance, okay, 62 00:02:51.080 --> 00:02:53.719 and thread A is reading that balance to display it 63 00:02:53.759 --> 00:02:56.400 on a screen for you. But at that exact millisecond, 64 00:02:56.439 --> 00:02:59.479 thread B in the background mutates that variable to process 65 00:02:59.479 --> 00:03:00.520 a subscription fee. 66 00:03:00.560 --> 00:03:02.919 Oh wow, so thread A suddenly grabs the wrong number. 67 00:03:03.080 --> 00:03:06.840 Exactly. In an imperative program the state is the shared, 68 00:03:07.000 --> 00:03:10.919 constantly shifting battleground. Anyone can change it, so. 69 00:03:10.879 --> 00:03:13.800 It's basically like a chalkboard where you keep erasing and 70 00:03:13.840 --> 00:03:16.639 rewriting a running tally, and if someone erases it while 71 00:03:16.680 --> 00:03:18.360 you're looking away, you're messed up. 72 00:03:18.479 --> 00:03:20.039 That is a perfect analogy. 73 00:03:20.199 --> 00:03:24.319 Yes, so functional programming then basically removes the. 74 00:03:24.319 --> 00:03:27.960 Eraser precisely, it takes the eraser completely out of the equation. 75 00:03:28.520 --> 00:03:32.120 In this paradigm, a variable isn't a storage container you 76 00:03:32.120 --> 00:03:35.560 can just overwrite. It's more like a prominent mathematical binding. 77 00:03:36.000 --> 00:03:38.879 It's like carving a number into a stone tablet. 78 00:03:39.120 --> 00:03:42.280 I like that carved in stone. So once X is 79 00:03:42.319 --> 00:03:44.840 tied to the value of five, it is five forever. 80 00:03:45.000 --> 00:03:47.479 And if you want a new state, like if the 81 00:03:47.479 --> 00:03:48.960 bank balance changes. 82 00:03:48.719 --> 00:03:51.439 You don't mutate X. You have to evaluate a completely 83 00:03:51.479 --> 00:03:54.159 new expression that outputs a new value. You carve a 84 00:03:54.199 --> 00:03:54.879 new tablet. 85 00:03:55.039 --> 00:03:56.719 So you never actually change the data. 86 00:03:56.800 --> 00:04:00.159 Nope, you only pass it through functions to create new data. 87 00:04:00.240 --> 00:04:02.599 But how does that actually help with the bank balance problem. 88 00:04:02.680 --> 00:04:06.240 Well, that permanent binding changes the literal physics of the software. 89 00:04:06.639 --> 00:04:10.960 Because you never erase or mutate anything. You completely eliminate 90 00:04:11.000 --> 00:04:12.800 those side effects we talked about. 91 00:04:12.599 --> 00:04:14.800 Oh, because nothing can sneak in and change the data 92 00:04:14.800 --> 00:04:16.480 behind your back exactly. 93 00:04:16.720 --> 00:04:19.879 A function in this world is mathematically pure. It receives 94 00:04:19.920 --> 00:04:22.839 an input, does its calculation, and returns an output. 95 00:04:23.000 --> 00:04:24.199 It's totally isolated. 96 00:04:24.319 --> 00:04:27.680 Right, it's a hermetically sealed unit of logic. It cannot 97 00:04:27.720 --> 00:04:30.639 secretly reach outside of itself and mess with a global 98 00:04:30.639 --> 00:04:33.360 counter or access a database in the background. 99 00:04:33.439 --> 00:04:36.000 Okay, hold on, I understand the security of a hermetically 100 00:04:36.000 --> 00:04:41.639 sealed function. But and here's the catch. In a physical machine, 101 00:04:41.680 --> 00:04:44.360 things physically have to happen one after another in. 102 00:04:44.319 --> 00:04:45.639 Our standard view of time. 103 00:04:45.720 --> 00:04:49.079 Yes, right, If I write a program in an imperative language, 104 00:04:49.480 --> 00:04:51.920 the order of my commands is life. Rather, if I 105 00:04:52.000 --> 00:04:54.480 swap lines of code, the program. 106 00:04:54.160 --> 00:04:57.480 Just crashes because line three depends on the mutated state 107 00:04:57.560 --> 00:04:59.160 created by line two exactly. 108 00:04:59.160 --> 00:04:59.920 Sequence dictates. 109 00:05:00.240 --> 00:05:03.839 Well, that's the imperative prison. Right. You are basically chained 110 00:05:03.879 --> 00:05:08.759 to time. But because functional programming prohibits mutation entirely, time 111 00:05:08.839 --> 00:05:12.959 loses its authority over the code. Wait really, yeah, execution 112 00:05:13.120 --> 00:05:14.480 order simply ceases to matter. 113 00:05:14.759 --> 00:05:19.199 That sounds physically impossible. How can a machine process logic 114 00:05:19.279 --> 00:05:22.560 without a sequence. Doesn't the program need to know what 115 00:05:22.680 --> 00:05:25.160 to execute first to feed into the next step. 116 00:05:25.399 --> 00:05:29.040 It relies on this really elegant mathematical principle called the 117 00:05:29.160 --> 00:05:31.920 Church Rosser theorem. Okay, way on me, Let's look at 118 00:05:31.920 --> 00:05:36.600 a basic arithmetic expression, say two plus three in parentheses 119 00:05:36.759 --> 00:05:39.240 multiplied by four plus five in parentheses. 120 00:05:40.000 --> 00:05:40.199 Right. 121 00:05:41.079 --> 00:05:44.199 Because these are pure values with no hidden side effects, 122 00:05:44.439 --> 00:05:46.959 it genuinely does not matter if you calculate the two 123 00:05:47.040 --> 00:05:50.279 plus three first or if you calculate the four plus five. 124 00:05:50.079 --> 00:05:52.040 First, because they don't impact each other. 125 00:05:51.959 --> 00:05:54.600 Exactly, you will arrive at forty five either way. 126 00:05:54.720 --> 00:05:56.600 Okay, that makes sense in a small scale. 127 00:05:56.639 --> 00:06:00.879 Well, the church Rosso theorem mathematically proves that if a 128 00:06:00.959 --> 00:06:05.120 functional program terminates, it will yield the exact same final 129 00:06:05.160 --> 00:06:08.199 result regardless of the order in which its sub expressions 130 00:06:08.199 --> 00:06:08.959 are evaluated. 131 00:06:09.120 --> 00:06:11.920 Ah So, because the functions are pure, they just don't 132 00:06:11.920 --> 00:06:14.600 care who finishes first. They aren't waiting on some global 133 00:06:14.680 --> 00:06:16.079 variable to change somewhere else. 134 00:06:16.240 --> 00:06:18.920 What's fascinating here is what happens when you scale that 135 00:06:19.000 --> 00:06:23.000 concept up. You suddenly see why massive tech companies like 136 00:06:23.079 --> 00:06:25.480 Google and Amazon care deeply about this. 137 00:06:25.720 --> 00:06:29.120 Oh, because if execution order doesn't matter, you aren't limited 138 00:06:29.199 --> 00:06:32.439 to running your program on just one processor exactly. 139 00:06:32.720 --> 00:06:35.560 You can take a massive functional program, shatter it into 140 00:06:35.600 --> 00:06:38.879 a million independent pieces, and farm those pieces out to 141 00:06:39.000 --> 00:06:41.800 tens of thousands of cheap servers simultaneously. 142 00:06:42.360 --> 00:06:45.160 That is incredible, and Michaelson actually notes this in his 143 00:06:45.199 --> 00:06:49.639 twenty eleven preface right that Google's map produce framework is 144 00:06:49.680 --> 00:06:51.439 built directly on these concepts. 145 00:06:51.480 --> 00:06:54.279 He does, map reduce is the engine that made their 146 00:06:54.279 --> 00:06:56.759 search indexing so incredibly fast. 147 00:06:56.920 --> 00:06:59.199 How does that actually map to functional programming? Though? 148 00:06:59.439 --> 00:07:03.319 So the map function processes data independently across thousands of 149 00:07:03.360 --> 00:07:06.639 machines without any shared state, and then the reduced function 150 00:07:06.800 --> 00:07:08.800 aggregates all those pure outputs. 151 00:07:08.839 --> 00:07:12.079 So there are no locks, no race conditions, no side effects, none. 152 00:07:12.199 --> 00:07:13.480 It's perfectly parallel. 153 00:07:13.720 --> 00:07:16.759 Okay, I see how that enables massive parallel processing for 154 00:07:17.120 --> 00:07:20.680 a tech giant. But let me challenge the everyday utility 155 00:07:20.680 --> 00:07:21.399 of this for a second. 156 00:07:21.519 --> 00:07:22.000 Go for it. 157 00:07:22.160 --> 00:07:24.600 If I have no sequence and I'm not allowed to 158 00:07:24.680 --> 00:07:28.240 mutate a variable, how do I actually do something repetitive? 159 00:07:28.279 --> 00:07:29.199 How do I iterate? 160 00:07:29.360 --> 00:07:30.240 Give me an example? 161 00:07:30.319 --> 00:07:32.759 Okay, say I want to search through a list of 162 00:07:32.759 --> 00:07:36.639 a million log files to find one specific error code. 163 00:07:36.680 --> 00:07:39.879 In normal imperative code, I write a standard for loop. 164 00:07:40.600 --> 00:07:43.319 I use a counter variable what's called I, and I 165 00:07:43.439 --> 00:07:46.800 mutate I from one to a million, checking the list 166 00:07:46.839 --> 00:07:47.399 each time. 167 00:07:47.680 --> 00:07:48.560 The classic approach. 168 00:07:48.639 --> 00:07:51.199 Sure, right, So how do you loop without a counter. 169 00:07:51.319 --> 00:07:53.199 Well you don't. You don't use loops at all. 170 00:07:53.360 --> 00:07:54.399 Wait what no loops? 171 00:07:54.439 --> 00:07:57.720 No loops. Loops inherently require state mutation. You have to 172 00:07:57.800 --> 00:08:01.800 update that counter instead. Functional programming relies on recursion. 173 00:08:02.160 --> 00:08:04.959 Okay, recursion, how does that work? In this context? 174 00:08:05.199 --> 00:08:07.920 You have a function that processes the very first item 175 00:08:07.920 --> 00:08:10.240 in the list, just the first one. If it's not 176 00:08:10.279 --> 00:08:12.720 the error code you're looking for. The function calls a 177 00:08:12.879 --> 00:08:15.959 brand new, pristine copy of itself. Oh, I see it, 178 00:08:15.959 --> 00:08:17.839 and it passes the remainder of the list to that 179 00:08:17.959 --> 00:08:18.600 new copy. 180 00:08:18.800 --> 00:08:20.920 Okay, let me make sure I'm visualizing this right. So 181 00:08:20.959 --> 00:08:23.439 instead of one runner running a million laps and checking 182 00:08:23.480 --> 00:08:26.560 a stopwatch every time, you basically have a relay race 183 00:08:26.600 --> 00:08:28.319 with a million distinct runners. 184 00:08:28.480 --> 00:08:30.120 Yes, that's a great way to put it. 185 00:08:30.319 --> 00:08:33.360 Each runner only runs one step, looks at the data, 186 00:08:33.759 --> 00:08:36.960 and passes the baton to a totally new clone of themselves. 187 00:08:37.240 --> 00:08:40.600 That's a very solid way to visualize it. Every recursive 188 00:08:40.679 --> 00:08:45.879 call creates a completely fresh execution context. You never change 189 00:08:45.879 --> 00:08:46.679 the original list. 190 00:08:46.759 --> 00:08:48.960 You just keep peeling off the first element and passing 191 00:08:49.000 --> 00:08:49.480 the rest for. 192 00:08:49.519 --> 00:08:53.120 Us exactly, and this forces a radically different approach to 193 00:08:53.440 --> 00:08:56.919 data structures as a whole because there's no assignment. There 194 00:08:56.919 --> 00:09:00.159 are no arrays where you can just tweak element number four. 195 00:09:00.600 --> 00:09:01.919 Right, because you can't mutate it. 196 00:09:02.000 --> 00:09:06.240 You have to explicitly pass entire nested structures through these 197 00:09:06.279 --> 00:09:10.440 recursive chains, and you rely heavily on abstraction to keep 198 00:09:10.480 --> 00:09:11.679 the logic clean. 199 00:09:11.879 --> 00:09:15.399 Which brings us to chapter two. Michaelson dedicates that whole 200 00:09:15.480 --> 00:09:18.159 chapter to the concept of abstraction, and it seems really 201 00:09:18.200 --> 00:09:18.960 pivotal here. 202 00:09:19.120 --> 00:09:23.240 It is without abstraction, this whole system collapses under its 203 00:09:23.279 --> 00:09:23.679 own weight. 204 00:09:23.879 --> 00:09:27.399 Because abstraction isn't just about hiding complexity, right, It's about 205 00:09:27.440 --> 00:09:32.039 shifting from concrete values to generalized rules exactly. 206 00:09:32.320 --> 00:09:36.120 Michaelson gives a great simple example. If you are calculating 207 00:09:36.159 --> 00:09:39.000 the cost of a shopping cart. You don't hard code 208 00:09:39.080 --> 00:09:40.679 nine items times ten cents. 209 00:09:40.879 --> 00:09:44.240 You introduce names like quantity in price, right. 210 00:09:44.399 --> 00:09:49.080 You abstract the specific operation into a general, pure rule. 211 00:09:49.759 --> 00:09:53.200 Here's where it gets really interesting, though. Functional programming takes 212 00:09:53.279 --> 00:09:56.480 this a step further. It doesn't just abstract data, it 213 00:09:56.519 --> 00:09:58.399 abstracts the operations themselves. 214 00:09:58.600 --> 00:10:02.399 Yes, functions are tree as first class citizens. 215 00:10:02.120 --> 00:10:04.360 Which sounds fancy, but what does it actually mean. 216 00:10:04.399 --> 00:10:07.759 In practice, it means functions are treated exactly like data. 217 00:10:07.879 --> 00:10:10.440 You can pass a function into another function as. 218 00:10:10.360 --> 00:10:12.279 An argument, like passing a number. 219 00:10:12.120 --> 00:10:14.679 Exactly the same. You can even write a function whose 220 00:10:14.759 --> 00:10:18.200 only job is to dynamically construct and spit out an 221 00:10:18.320 --> 00:10:20.919 entirely new function based on the input it received. 222 00:10:21.039 --> 00:10:24.519 That is wild. You are manipulating logic the exact same 223 00:10:24.559 --> 00:10:25.960 way you manipulate integers. 224 00:10:26.159 --> 00:10:27.879 It is a total paradigm shift. 225 00:10:28.240 --> 00:10:31.559 And the ultimate expression of that is Lisp right list processing. 226 00:10:31.600 --> 00:10:34.039 I know it's one of the earliest languages to adopt 227 00:10:34.039 --> 00:10:34.759 these concepts. 228 00:10:34.840 --> 00:10:37.639 Oh LSP is legendary for this because. 229 00:10:37.360 --> 00:10:40.799 In LASP, the syntax you write to create the program 230 00:10:41.200 --> 00:10:43.480 is literally just a nested list itself. 231 00:10:43.559 --> 00:10:46.919 Right, So the command add two three is mathematically the 232 00:10:46.960 --> 00:10:50.159 same fundamental data structure as a list of groceries like 233 00:10:50.639 --> 00:10:51.720 Apple's milk bread. 234 00:10:52.080 --> 00:10:54.600 The code is data and the data is code. I 235 00:10:54.600 --> 00:10:57.080 think the technical term is homo econicity. 236 00:10:57.159 --> 00:10:59.519 Homo econicity. Yes, it's a bit of a mouthful, but 237 00:10:59.559 --> 00:11:03.840 it basically it means an Lisp program can effortlessly read, rewrite, 238 00:11:03.919 --> 00:11:06.480 and generate other Lisp programs. 239 00:11:06.080 --> 00:11:07.399 On the fly, mind bending. 240 00:11:07.759 --> 00:11:12.559 It creates this incredible fluidity. Imperative languages which strictly separate 241 00:11:12.559 --> 00:11:15.799 the compiled instructions from the memory heap, they simply cannot 242 00:11:15.879 --> 00:11:16.320 mimic that. 243 00:11:16.559 --> 00:11:18.440 But you know what makes this so compelling isn't just 244 00:11:18.480 --> 00:11:20.440 the architecture itself. It's the origin story. 245 00:11:20.559 --> 00:11:22.679 Oh, the history is fascinating. 246 00:11:22.200 --> 00:11:25.919 Right, because this entirely alien way of structuring computation was 247 00:11:25.960 --> 00:11:29.120 not invented by some modern computer scientists trying to optimize 248 00:11:29.200 --> 00:11:30.240 cloud networkloads. 249 00:11:30.519 --> 00:11:32.000 Not at all. It's way older than that. 250 00:11:32.399 --> 00:11:36.559 It was born from a profound philosophical crisis among mathematicians 251 00:11:36.600 --> 00:11:37.720 in the nineteen thirties. 252 00:11:37.759 --> 00:11:39.759 We really have to rewind the tape to understand this. 253 00:11:40.039 --> 00:11:44.159 Long before silicon ships even existed, mathematicians were obsessed with 254 00:11:44.240 --> 00:11:45.320 a seemingly. 255 00:11:45.080 --> 00:11:47.919 Simple question, is math unbreakable? 256 00:11:48.120 --> 00:11:51.399 Exactly? Is it perfect? So in the nineteen twenties, the 257 00:11:51.440 --> 00:11:56.159 German mathematician David Hilbert proposed what became known as Hilbert's program. 258 00:11:56.320 --> 00:11:57.399 Okay, what was his goal? 259 00:11:57.600 --> 00:12:00.919 He wanted to formally prove that mathematics was both consistent 260 00:12:01.240 --> 00:12:02.000 and complete. 261 00:12:02.320 --> 00:12:05.320 Those words probably have very strict definitions in this context. 262 00:12:05.559 --> 00:12:09.000 Very strict consistent means you can never use the rules 263 00:12:09.000 --> 00:12:12.600 of math to prove a contradiction like you can't logically 264 00:12:12.679 --> 00:12:14.279 prove that one equals two. 265 00:12:14.360 --> 00:12:16.360 That makes sense and complete. 266 00:12:16.120 --> 00:12:19.799 Complete means that every single true mathematical statement has a 267 00:12:19.840 --> 00:12:23.399 definitive proof that can be derived from the foundational axioms. 268 00:12:22.840 --> 00:12:25.440 So no mysteries, everything can be proven right. 269 00:12:25.759 --> 00:12:28.759 Hilbert wanted to build a perfect mechanized system of logic 270 00:12:28.879 --> 00:12:32.080 where literally any problem could eventually be solved just by 271 00:12:32.080 --> 00:12:34.080 turning the crank of mathematical rules. 272 00:12:34.320 --> 00:12:38.440 A beautiful dream, and then Kirk Godel totally shattered that 273 00:12:38.559 --> 00:12:39.919 dream in nineteen thirty one. 274 00:12:40.279 --> 00:12:45.039 He utterly obliterated it with his incompleteness theorems how did 275 00:12:45.039 --> 00:12:47.799 you do it? Godel realized that if a formal system 276 00:12:47.879 --> 00:12:51.399 is complex enough to handle basic arithmetic, it can actually 277 00:12:51.440 --> 00:12:52.759 be made to talk about itself. 278 00:12:52.919 --> 00:12:55.279 Okay, this is getting a bit meta. 279 00:12:54.799 --> 00:12:58.240 It is. He developed this brilliant technique called Godal numbering, 280 00:12:58.559 --> 00:13:01.840 where he assigned a unie nique numerical code to every 281 00:13:01.919 --> 00:13:03.679 mathematical symbol and operation. 282 00:13:04.000 --> 00:13:07.120 So he basically turned mathematical equations into a kind of 283 00:13:07.159 --> 00:13:11.039 programming language that could output statements about its own code. 284 00:13:11.240 --> 00:13:14.320 Yes, and using that he encoded a mathematical statement that 285 00:13:14.360 --> 00:13:17.519 translated essentially to this statement cannot be proven. 286 00:13:17.639 --> 00:13:19.960 Oh wow. It's a classic liar's. 287 00:13:19.679 --> 00:13:24.039 Paradox, but weaponized against arithmetic itself. Think about it. If 288 00:13:24.039 --> 00:13:26.440 the statement is false, it means it can be proven, 289 00:13:26.720 --> 00:13:29.799 which means math just proved a falsehood, making the entire 290 00:13:29.840 --> 00:13:31.559 field of mathematics inconsistent. 291 00:13:31.840 --> 00:13:33.200 And if the statement is true. 292 00:13:33.279 --> 00:13:35.159 If the statement is true, it means there is a 293 00:13:35.200 --> 00:13:39.440 true mathematical fact that lacks a proof, meaning mathematics is 294 00:13:39.600 --> 00:13:40.960 fundamentally incomplete. 295 00:13:41.399 --> 00:13:44.360 Wow. So there are true things we can never mathematically 296 00:13:44.399 --> 00:13:45.600 prove exactly. 297 00:13:45.679 --> 00:13:47.960 It's a devastating realization for mathematicians. 298 00:13:47.960 --> 00:13:51.600 I can imagine. Yeah, but the ashes of Hilbert's program 299 00:13:51.679 --> 00:13:53.720 triggered this incredible race, didn't. 300 00:13:53.519 --> 00:13:58.159 It It did. If math has limits, mathematicians urgently needed 301 00:13:58.200 --> 00:14:01.720 to define exactly what could be computed, Like what are. 302 00:14:01.600 --> 00:14:03.919 The strict boundaries of mechanical calculation? 303 00:14:04.080 --> 00:14:08.320 Right? And in nineteen thirty six, two brilliant thinkers published 304 00:14:08.320 --> 00:14:11.240 two completely different road maps for computability. 305 00:14:11.320 --> 00:14:14.919 This is where the timeline of human technology literally splits. 306 00:14:15.240 --> 00:14:18.039 It really does. On one side, you have Alan Turing. 307 00:14:18.559 --> 00:14:21.720 Turing defined computability using a theoretical. 308 00:14:21.200 --> 00:14:23.080 Machine, the famous Turing machine. 309 00:14:23.159 --> 00:14:26.799 Right picture an infinite tape divided into squares with a 310 00:14:26.840 --> 00:14:29.799 read right head, moving left and right, erasing and rewriting 311 00:14:29.879 --> 00:14:32.000 symbols one step at a time based on a set 312 00:14:32.000 --> 00:14:32.840 of rules. 313 00:14:32.559 --> 00:14:36.000 And that tape inherently implies sequence. It moves forward, it 314 00:14:36.039 --> 00:14:38.679 moves backward, It updates the state of the squares during 315 00:14:38.759 --> 00:14:41.960 basically formalized the imperative model we talked about earlier. Do 316 00:14:42.039 --> 00:14:42.919 this change that? 317 00:14:43.279 --> 00:14:45.399 Move here exactly. And on the other side of this 318 00:14:45.440 --> 00:14:48.480 you have Alonzo Church, who is actually Turing's doctoral advisor. 319 00:14:48.679 --> 00:14:50.120 Oh really, I didn't know that. 320 00:14:50.399 --> 00:14:53.480 Yeah, and Church didn't care about tapes or machines or sequence. 321 00:14:53.840 --> 00:14:56.200 He created lambda calculus. 322 00:14:55.840 --> 00:14:58.159 Which is the foundation of functional programming. 323 00:14:58.320 --> 00:15:02.000 Yes, it is a formal system based entirely on stateless function, 324 00:15:02.080 --> 00:15:07.360 abstraction and variable substitution. No tape, no time, no mutation, just. 325 00:15:07.320 --> 00:15:09.679 Pure expressions evaluating other expressions. 326 00:15:09.879 --> 00:15:12.320 If we connect this to the bigger picture, the ultimate 327 00:15:12.360 --> 00:15:16.519 plot twist here is Church's thesis. Turing and Church actually 328 00:15:16.559 --> 00:15:20.519 prove that their completely divergent systems were mathematically equivalent. 329 00:15:20.720 --> 00:15:23.519 Wait, really, the tape and the stateless equations are the same. 330 00:15:23.679 --> 00:15:27.720 Yes, anything you can compute on Turing's sequential tape, you 331 00:15:27.720 --> 00:15:32.080 can compute using Church's timeless lambda equations. They defined the 332 00:15:32.120 --> 00:15:35.679 exact same universe of computability. They were just speaking two 333 00:15:35.679 --> 00:15:37.600 completely different dialects. 334 00:15:37.240 --> 00:15:40.720 But those dialects had massive real world implications. 335 00:15:40.879 --> 00:15:45.559 Huge implications Turing's model maps beautifully onto physical. 336 00:15:45.080 --> 00:15:47.840 Reality because a read write head moving along a tape 337 00:15:47.879 --> 00:15:51.320 is conceptually identical to an electrical switch turning on and 338 00:15:51.360 --> 00:15:53.759 off to update a memory register exactly. 339 00:15:53.799 --> 00:15:58.000 So when engineers built the first digital computers, they basically 340 00:15:58.000 --> 00:16:00.320 built physical Turing machines, and. 341 00:16:00.320 --> 00:16:04.399 So imperative programming languages like Fortran and c were designed 342 00:16:04.399 --> 00:16:06.799 to orchestrate those physical state changes. 343 00:16:07.039 --> 00:16:11.120 While Church's lambda calculus, despite being mathematically pure and beautiful, 344 00:16:11.759 --> 00:16:14.600 was just too abstract for early hardware. It got relegated 345 00:16:14.600 --> 00:16:15.279 to academia. 346 00:16:15.399 --> 00:16:16.879 Well until the nineteen eighties. 347 00:16:16.600 --> 00:16:18.480 Anyway, Right the eighties changed things. 348 00:16:18.879 --> 00:16:23.039 Michaelson's twenty eleven preface spends a lot of time dissecting 349 00:16:23.279 --> 00:16:27.159 this massive resurgence of functional programming during that era. 350 00:16:27.399 --> 00:16:30.200 What happened the tech industry hit a wall. It was 351 00:16:30.240 --> 00:16:32.639 widely known as the software crisis. 352 00:16:32.240 --> 00:16:34.120 Because of the side effects. We talked about. 353 00:16:33.919 --> 00:16:38.200 Exactly, because imperative programs rely on mutating shared state. As 354 00:16:38.279 --> 00:16:41.879 programs grew larger and larger, the side effects became impossible 355 00:16:41.879 --> 00:16:42.879 for humans to manage. 356 00:16:42.960 --> 00:16:46.679 I'm guessing bugs were just multiplying exponentially. Code was crashing 357 00:16:46.759 --> 00:16:47.399 left and right. 358 00:16:47.759 --> 00:16:50.600 There was a genuine panic in the industry. The Japanese 359 00:16:50.639 --> 00:16:54.799 government actually launched the Fifth Generation Computing Initiative, aiming to 360 00:16:54.840 --> 00:16:57.320 build machines that ran entirely on pure. 361 00:16:57.080 --> 00:17:00.039 Logic, and the UK responded to that right they did. 362 00:17:00.120 --> 00:17:03.960 The ALVI program. They heavily funded functional languages like Hope, 363 00:17:04.519 --> 00:17:06.720 mL and eventually Haskell. 364 00:17:07.200 --> 00:17:11.839 Because a pitch was incredibly alluring. Just abandoned imperative state, 365 00:17:11.920 --> 00:17:16.240 adopt Church's timeless mathematics, and your code will be theoretically 366 00:17:16.240 --> 00:17:18.039 bug free and mathematically provable. 367 00:17:18.119 --> 00:17:20.480 It was touted as a total silver bullet. 368 00:17:20.839 --> 00:17:24.440 So what does this all mean? If it was mathematically superior, 369 00:17:24.839 --> 00:17:27.480 why did it fail to take over the industry, Why 370 00:17:27.519 --> 00:17:31.359 did messy imperative languages like C plus plus and Java 371 00:17:31.759 --> 00:17:32.720 end up winning the war? 372 00:17:32.880 --> 00:17:36.279 Well, Michael Sola is refreshingly honest about this in his preface. 373 00:17:36.720 --> 00:17:40.319 Pure declarative and functional languages were basically overhyped because they 374 00:17:40.319 --> 00:17:43.640 ignored the fundamental nature of reality, meaning what exactly, meaning 375 00:17:43.680 --> 00:17:47.400 the physical world is inherently stateful. Time exists, oh or right, 376 00:17:47.480 --> 00:17:50.000 when a human interacts with a computer, clicking a button, 377 00:17:50.160 --> 00:17:52.720 typing a word, saving a file to a hard drive, 378 00:17:53.240 --> 00:17:56.079 those are sequential events. They literally mutate the state of 379 00:17:56.119 --> 00:17:56.440 the world. 380 00:17:56.680 --> 00:17:59.920 Ah. If pure functional programming doesn't allow side of it 381 00:18:00.000 --> 00:18:03.039 effects or state changes, how do you even update a 382 00:18:03.119 --> 00:18:05.640 database or draw a pixel on a screen? 383 00:18:05.920 --> 00:18:09.559 You see the problem. It becomes incredibly cumbersome. You have 384 00:18:09.640 --> 00:18:14.599 to invent these hugely complex mathematical workarounds, things called monads, 385 00:18:15.359 --> 00:18:18.559 just to allow a pure function to interact with the messy, 386 00:18:19.000 --> 00:18:21.359 time bound reality of a user interface. 387 00:18:21.839 --> 00:18:25.880 So pure functional programming is brilliant beyond time, but it 388 00:18:26.000 --> 00:18:29.839 is deeply awkward when forced to operate within time. 389 00:18:30.319 --> 00:18:34.799 That's a great summary. Therefore, imperative languages maintain their dominance 390 00:18:34.839 --> 00:18:39.319 for writing operating systems, desktop applications, and user interfaces. 391 00:18:40.000 --> 00:18:42.440 But the narrative doesn't just end in the eighties, obviously, 392 00:18:42.440 --> 00:18:43.799 since we're still talking about it today. 393 00:18:43.839 --> 00:18:46.200 No, it doesn't, because the Internet changed the scale of 394 00:18:46.240 --> 00:18:47.200 software completely. 395 00:18:47.359 --> 00:18:49.759 Right. We move from desktop apps running on a single 396 00:18:49.799 --> 00:18:54.839 CPU to these distributed cloud systems running across ten thousand nodes, and. 397 00:18:54.839 --> 00:18:57.480 Suddenly we hit the limits of Turing's tape all over. 398 00:18:57.359 --> 00:18:59.559 Again, because when you have a million users hitting at 399 00:18:59.599 --> 00:19:04.599 database simultaneously, imperative state mutation becomes your biggest bottleneck. 400 00:19:04.759 --> 00:19:07.799 Exactly, you spend all your processing power just trying to 401 00:19:07.880 --> 00:19:10.920