WEBVTT 1 00:00:00.120 --> 00:00:03.680 You know, you open a banking app and your balance 2 00:00:03.720 --> 00:00:06.879 just appears instantly, or you stream a movie and the 3 00:00:06.960 --> 00:00:08.400 video renders without a stutter. 4 00:00:08.679 --> 00:00:10.560 Right, it basically feels like magic, It. 5 00:00:10.480 --> 00:00:14.720 Really does, but it's actually driven by this invisible, ancient architecture. 6 00:00:14.919 --> 00:00:18.719 An architecture built on rules so rigid that well, as 7 00:00:18.719 --> 00:00:22.039 we found in today's source material, asking a computer for 8 00:00:22.079 --> 00:00:25.640 the absolute value of a negative number can actually spit 9 00:00:25.719 --> 00:00:27.199 out a negative result. 10 00:00:26.879 --> 00:00:28.719 Which is pretty wild to think about. 11 00:00:29.000 --> 00:00:32.320 Yeah, it completely breaks your brain at first. So welcome 12 00:00:32.359 --> 00:00:35.719 to this deep dive. Today we are digging into excerpts 13 00:00:35.719 --> 00:00:40.079 from the widely respected computer science textbook Algorithms, fourth Edition, 14 00:00:40.280 --> 00:00:44.000 Part one by Robert Sedgrick and Kevin Wayne from Princeton University. 15 00:00:44.039 --> 00:00:46.479 Then we should clarify our mission today isn't to, you know, 16 00:00:46.840 --> 00:00:48.439 teach you how to code line by line? 17 00:00:48.600 --> 00:00:49.960 No, definitely not right. 18 00:00:50.000 --> 00:00:52.799 This is for you, the intellectually curious listener. We want 19 00:00:52.840 --> 00:00:55.960 to extract the profound logic, the physical quirks, and the 20 00:00:56.000 --> 00:00:59.759 elegant problem solving strategies that programmers use to build well 21 00:01:00.159 --> 00:01:01.880 much everything in your digital life. 22 00:01:02.119 --> 00:01:05.879 Exactly. We're treating this material not as some dry programming 23 00:01:05.920 --> 00:01:09.640 manual but really as a philosophy of efficiency, because there 24 00:01:09.719 --> 00:01:14.840 is a vast unseen gulf between just hacking together code 25 00:01:14.840 --> 00:01:19.239 that technically runs and designing an elegant algorithm. 26 00:01:19.319 --> 00:01:22.319 Yeah, that difference is what separates a process that takes 27 00:01:22.439 --> 00:01:25.000 ten seconds from one that takes ten thousand years. 28 00:01:25.159 --> 00:01:28.760 Literally, and we hear the word algorithm tossed around constantly, 29 00:01:28.840 --> 00:01:32.560 right like the YouTube algorithm or stock trading algorithms. 30 00:01:32.120 --> 00:01:34.079 Become a huge Silicon Valley buzzword. 31 00:01:34.239 --> 00:01:37.000 It really has. But stripped of all that, the text 32 00:01:37.079 --> 00:01:40.879 defines an algorithm as simply a finite, deterministic, and effective 33 00:01:40.879 --> 00:01:42.239 method for solving a problem. 34 00:01:42.519 --> 00:01:46.519 Right. Finite meaning it actually has an end, deterministic meaning 35 00:01:46.640 --> 00:01:50.400 it behaves predictably every time, and effective meaning it actually 36 00:01:50.560 --> 00:01:52.439 solves the thing you wanted to solve. It's just a 37 00:01:52.439 --> 00:01:53.519 step by step procedure. 38 00:01:53.560 --> 00:01:55.079 And what really stood out to me in the text 39 00:01:55.120 --> 00:01:57.840 is that algorithms are not a modern invention at all. 40 00:01:57.879 --> 00:02:00.560 They aren't born in the age of microchips, not at all. 41 00:02:00.719 --> 00:02:04.000 The authors highlight Euclid's algorithm for finding the greatest common 42 00:02:04.040 --> 00:02:06.120 divisor of two numbers, and that. 43 00:02:06.079 --> 00:02:09.159 Was devised over two thousand, three hundred years ago. 44 00:02:09.240 --> 00:02:12.800 Yeah, over two millennia before the first computer was even plugged. 45 00:02:12.439 --> 00:02:16.319 In, just a guy in a toga writing algorithms. But 46 00:02:16.719 --> 00:02:19.560 you know, applying that to our modern context brings up 47 00:02:19.560 --> 00:02:22.199 a bit of skepticism for me. Also, well, we have 48 00:02:22.280 --> 00:02:24.599 phones in our pockets with more computing power than the 49 00:02:24.599 --> 00:02:28.639 apall emissions. Right, So if my program is running slow today, 50 00:02:29.159 --> 00:02:31.919 I have to wonder why we obsess so much over 51 00:02:32.000 --> 00:02:36.800 algorithmic efficiency, Like why not just buy a faster processor. 52 00:02:37.199 --> 00:02:40.080 Yeah, throwing hardware at a software problem is a really 53 00:02:40.080 --> 00:02:44.159 common instinct, but it completely breaks down when you hit 54 00:02:44.199 --> 00:02:47.439 the reality of big data. Okay, the text asserts that 55 00:02:47.479 --> 00:02:50.439 a well designed algorithm can make a program millions of 56 00:02:50.479 --> 00:02:54.759 times faster. Millions, Right, Buying new hardware might speed you're 57 00:02:54.800 --> 00:02:57.879 processing up by say a factor of ten, or if 58 00:02:57.879 --> 00:03:00.759 you buy a massive supercomputer, maybe a factor of one. 59 00:03:00.680 --> 00:03:02.439 Hundred, So a factor of one hundred versus a factor 60 00:03:02.479 --> 00:03:02.919 of a million. 61 00:03:03.039 --> 00:03:03.439 Exactly. 62 00:03:03.479 --> 00:03:05.560 To really visualize how that scales, we can look at 63 00:03:05.599 --> 00:03:09.319 the book's credit card whitelist scenario. I loved this exam 64 00:03:09.439 --> 00:03:11.919 it's a great one. So imagine you're a credit card 65 00:03:11.919 --> 00:03:16.319 company and you have a database of one million valid 66 00:03:16.560 --> 00:03:19.719 customer account numbers. That's your white list. Okay, On a 67 00:03:19.759 --> 00:03:24.159 busy day, you need to process ten million incoming transactions, 68 00:03:24.719 --> 00:03:28.479 and for every single transaction, the computer has to verify 69 00:03:28.599 --> 00:03:31.800 if that specific account number exists on the one million 70 00:03:31.879 --> 00:03:33.360 number whitelist, right. 71 00:03:33.360 --> 00:03:36.159 And if you approach that using what programmers call a 72 00:03:36.240 --> 00:03:38.919 brute force algorithm, it's a nightmare. 73 00:03:39.080 --> 00:03:40.919 How does the brute force way work? 74 00:03:41.000 --> 00:03:43.520 Well, you take the first of those ten million transactions 75 00:03:43.719 --> 00:03:45.759 and you compare it to the first number on your whitelist, 76 00:03:46.120 --> 00:03:47.560 then the second number, then the. 77 00:03:47.520 --> 00:03:51.680 Third, just checking every single card in a massive unsorted pile, 78 00:03:52.199 --> 00:03:53.680 one by one exactly. 79 00:03:53.719 --> 00:03:55.960 You might have to check hundreds of thousands of records 80 00:03:56.240 --> 00:03:58.159 just to verify one single transaction. 81 00:03:58.280 --> 00:04:00.240 I actually ran the math on this while reading. If 82 00:04:00.240 --> 00:04:02.960 you do that route force search for ten million transactions, 83 00:04:03.159 --> 00:04:06.680 your computer is performing up to ten trillion operations. 84 00:04:06.800 --> 00:04:07.520 Ten trillion. 85 00:04:07.639 --> 00:04:10.400 Yeah, even a modern processor is going to absolutely choke 86 00:04:10.479 --> 00:04:13.560 on ten trillion operations just to clear a day's worth 87 00:04:13.560 --> 00:04:15.280 of coffee purchases, Which is. 88 00:04:15.240 --> 00:04:19.120 Why the text introduces the concept of binary search. Now, 89 00:04:19.160 --> 00:04:22.399 this requires the underlying data to be perfectly sorted in 90 00:04:22.480 --> 00:04:23.319 numerical order. 91 00:04:23.439 --> 00:04:26.199 First, right, keeping the pile perfectly sorted. 92 00:04:26.360 --> 00:04:29.639 Yes, So when a new transaction comes in, instead of 93 00:04:29.680 --> 00:04:32.399 starting at the very beginning of the white list, the 94 00:04:32.439 --> 00:04:36.160 algorithm jumps straight to the exact middle of that sortid 95 00:04:36.160 --> 00:04:37.160 million record list. 96 00:04:37.319 --> 00:04:39.879 And since it's sorted, it just asks, is the transaction 97 00:04:40.000 --> 00:04:42.480 number larger or smaller than this middle number? 98 00:04:42.639 --> 00:04:46.319 Exactly if it's smaller, you know, for a mathematical fact, 99 00:04:46.319 --> 00:04:48.000 it has to be in the first half of the data. 100 00:04:48.040 --> 00:04:50.920 So you instantly throw away five hundred thousand records. 101 00:04:51.000 --> 00:04:54.360 You just have the problem in one single stepw Then 102 00:04:54.399 --> 00:04:56.279 you jump to the middle of the remaining half, and 103 00:04:56.319 --> 00:04:59.199 you repeat the process. You keep dividing the data in half. 104 00:04:59.720 --> 00:05:02.160 So so what used to take hundreds of thousands of 105 00:05:02.240 --> 00:05:05.199 linear checks now takes about twenty steps. 106 00:05:05.480 --> 00:05:08.920 That is insane. Doing twenty steps for those ten million 107 00:05:08.959 --> 00:05:12.240 transactions means you only do two hundred million operations in total. 108 00:05:12.680 --> 00:05:15.600 We went from ten trillion operations down to two hundred 109 00:05:15.639 --> 00:05:19.399 million just by organizing the data and changing the search strategy. 110 00:05:19.680 --> 00:05:22.160 You didn't buy a faster computer at all. You just 111 00:05:22.279 --> 00:05:23.720 used an elegant algorithm. 112 00:05:23.920 --> 00:05:27.199 And that is really the philosophical core of computer science. 113 00:05:27.279 --> 00:05:30.879 It's fascinating, but to execute that twenty step binary search 114 00:05:30.920 --> 00:05:33.600 at lightning speed. The computer has to build it out 115 00:05:33.600 --> 00:05:35.439 of raw materials right right. 116 00:05:35.839 --> 00:05:39.040 In Java and a lot of other programming languages, the 117 00:05:39.319 --> 00:05:43.079 absolute bedrock is what we call primitive data types. 118 00:05:42.920 --> 00:05:45.040 The basic atoms of the language. 119 00:05:44.600 --> 00:05:49.160 Exactly your standard integers, real numbers, boollions, characters. And what 120 00:05:49.199 --> 00:05:51.199 the text points out is that because these primitives are 121 00:05:51.240 --> 00:05:54.879 so closely tied to the physical hardware memory, they carry 122 00:05:54.920 --> 00:05:56.680 some pretty dangerous limitations. 123 00:05:56.759 --> 00:05:59.680 Oh yeah, they are deeply bound by the physical laws 124 00:05:59.680 --> 00:06:01.959 inside the machine. You see this right away in the 125 00:06:01.959 --> 00:06:04.759 textbook's Q and A section regarding how arrays work. 126 00:06:04.959 --> 00:06:06.000 The zero index thing. 127 00:06:06.199 --> 00:06:08.959 Yes, an array is just the sequence of these primitive 128 00:06:09.040 --> 00:06:12.920 value stored together, and programmers famously do not start counting 129 00:06:12.959 --> 00:06:15.319 an array at one. They start at zero. The first 130 00:06:15.319 --> 00:06:17.000 item is at index zero. 131 00:06:17.079 --> 00:06:19.720 Which is entirely counterintuitive to human counting. 132 00:06:19.879 --> 00:06:21.759 Right. If I have three apples, I don't call the 133 00:06:21.800 --> 00:06:22.959 first one apple zero. 134 00:06:23.240 --> 00:06:25.680 No, But it makes perfect sense to the hardware. You see, 135 00:06:25.720 --> 00:06:28.879 in physical memory, an array is a contiguous block of space. 136 00:06:29.439 --> 00:06:32.079 The index isn't actually a human tally at all. It 137 00:06:32.160 --> 00:06:34.879 is a mathematical offset from the starting memory address of 138 00:06:34.920 --> 00:06:35.399 that array. 139 00:06:35.680 --> 00:06:38.160 Ah. Okay, So the first item has an offset of 140 00:06:38.279 --> 00:06:41.319 zero because it sits exactly at the starting address. 141 00:06:41.040 --> 00:06:44.279 Precisely, and the second item is offset by one memory slot. 142 00:06:44.560 --> 00:06:47.720 It was designed that way historically to save the CPU 143 00:06:47.839 --> 00:06:50.720 from having to do an extra subtraction step every single 144 00:06:50.800 --> 00:06:51.560 time it looked. 145 00:06:51.399 --> 00:06:54.600 Up a value, because ringing every last drop of efficiency 146 00:06:54.600 --> 00:06:56.120 out of those old machines. 147 00:06:55.759 --> 00:07:01.120 Was paramount exactly. But prioritizing hardware speed over human logic 148 00:07:01.680 --> 00:07:05.480 creates these bizarre anomalies, which brings us to that math 149 00:07:05.519 --> 00:07:07.360 dot abs function you mentioned in the intro. 150 00:07:07.519 --> 00:07:10.680 This mind bending anomaly drove me crazy when I read it. Okay, 151 00:07:10.720 --> 00:07:13.240 So if you ask Java to give you the absolute 152 00:07:13.319 --> 00:07:17.319 value of negative two billion, one hundred forty seven million, 153 00:07:17.560 --> 00:07:20.399 four hundred eighty three thousand, six hundred thirty eight, that's 154 00:07:20.399 --> 00:07:22.680 a mouthful, it is. But if you put that into 155 00:07:22.680 --> 00:07:26.040 the math dot apps function, it returns negative two billion, 156 00:07:26.319 --> 00:07:29.360 one hundred forty seven million, four hundred eighty three thousand, 157 00:07:29.519 --> 00:07:30.360 six hundred. 158 00:07:30.120 --> 00:07:31.639 Forty eight, a negative answer. 159 00:07:31.800 --> 00:07:35.879 Yes, a computer is essentially a giant calculator, spitting out 160 00:07:35.920 --> 00:07:39.839 a strictly negative answer when explicitly asked for an absolute value, 161 00:07:40.240 --> 00:07:43.000 feels like it's breaking its own fundamental laws. 162 00:07:43.079 --> 00:07:46.839 It totally feels broken, but it perfectly illustrates something called 163 00:07:46.959 --> 00:07:48.240 inser overflow. 164 00:07:48.399 --> 00:07:49.680 Okay, break that down for me. 165 00:07:49.800 --> 00:07:53.600 Well, primitive data types are not abstract mathematical concepts floating 166 00:07:53.600 --> 00:07:56.920 out in the ether. They have strict physical memory limits. 167 00:07:57.560 --> 00:08:01.279 A standard injure in Java gets exactly thirty two bits 168 00:08:01.319 --> 00:08:02.920 of physical memory space. 169 00:08:03.160 --> 00:08:05.079 So it's kind of like the physical dials on a 170 00:08:05.120 --> 00:08:05.920 cars er doometer. 171 00:08:06.319 --> 00:08:07.800 That's a really good way to think about it. 172 00:08:07.839 --> 00:08:10.639 If the odomeinter only has six physical dials, it can 173 00:08:10.680 --> 00:08:13.920 only roll up to nine hundred ninety nine thousand, nine 174 00:08:14.000 --> 00:08:16.560 hundred and ninety nine, and then it runs out of 175 00:08:16.560 --> 00:08:19.199 space and clicks back over to all zeros. 176 00:08:19.560 --> 00:08:22.720 Right, and the binary architecture works similarly. A thirty two 177 00:08:22.759 --> 00:08:26.360 bit integer has a maximum positive limit of two billion, 178 00:08:26.720 --> 00:08:29.519 one hundred and forty seven million, four hundred eighty three thousand, 179 00:08:29.600 --> 00:08:33.120 six hundred forty seven Okay, But because of how the 180 00:08:33.120 --> 00:08:37.519 computer represents negative numbers in binary using a system called 181 00:08:37.600 --> 00:08:41.360 two's complement, the absolute lowest negative number it can hold 182 00:08:41.440 --> 00:08:44.960 is one unit larger. It's negative two billion, one hundred 183 00:08:45.000 --> 00:08:47.440 and forty seven million, four hundred and eighty three thousand, 184 00:08:47.480 --> 00:08:48.399 six hundred and forty eight. 185 00:08:48.440 --> 00:08:51.120 Wait, so it can hold one more negative number than 186 00:08:51.120 --> 00:08:52.480 it can positive numbers. 187 00:08:52.559 --> 00:08:55.480 Yes, because the zero takes up one of the positive 188 00:08:55.519 --> 00:08:56.759 slots in the binary structure. 189 00:08:56.799 --> 00:08:57.559 Oh, that makes sense. 190 00:08:57.639 --> 00:09:00.399 So here's the key. Would you try to find the 191 00:09:00.519 --> 00:09:04.519 absolute positive value of the absolute bottom floor number. The 192 00:09:04.559 --> 00:09:07.919 resulting positive number is one unit larger than the thirty 193 00:09:07.960 --> 00:09:09.759 two bit limit can physically hold. 194 00:09:09.879 --> 00:09:12.000 So the memory overflows exactly. 195 00:09:12.240 --> 00:09:15.240 It rolls past the maximum positive limit and clicks right 196 00:09:15.279 --> 00:09:18.600 back over into the extreme negative numbers, just like your odometer. 197 00:09:18.919 --> 00:09:22.240 That is wild. But the natural question here is why 198 00:09:22.240 --> 00:09:25.960 doesn't the programming language automatically catch that? I mean, we 199 00:09:26.000 --> 00:09:29.159 assume software should warn us if our math just broke 200 00:09:29.240 --> 00:09:31.159 the laws of physics inside the computer. 201 00:09:31.639 --> 00:09:34.320 Well, the designers made a very conscious choice there, speed 202 00:09:34.399 --> 00:09:35.039 over safety. 203 00:09:35.200 --> 00:09:36.279 Really yeah. 204 00:09:36.559 --> 00:09:38.440 The authors point out that if the computer had to 205 00:09:38.480 --> 00:09:42.399 run a secondary check on every single edition subtraction and 206 00:09:42.519 --> 00:09:46.559 multiplication to ensure it didn't overflow, programs would slow to 207 00:09:46.639 --> 00:09:48.120 an absolute. 208 00:09:47.559 --> 00:09:50.960 Crawl, So they just leave the responsibility entirely on the programmer. 209 00:09:51.039 --> 00:09:53.440 Pretty much, a little knowledge goes a long way. The 210 00:09:53.480 --> 00:09:55.720 program just has to use larger data types like a 211 00:09:55.799 --> 00:09:58.960 sixty four bit long integer if they anticipate working with 212 00:09:59.080 --> 00:10:00.000 numbers in the billions. 213 00:10:00.279 --> 00:10:03.519 So speed is king, even if it means silently returning 214 00:10:03.519 --> 00:10:07.000 a mathematically impossible answer. It kind of makes you realize 215 00:10:07.000 --> 00:10:10.639 that naked thirty two bit integers are way too risky 216 00:10:10.679 --> 00:10:14.960 and rigid for modeling complex real world systems. Oh absolutely, 217 00:10:15.039 --> 00:10:17.159 I mean, if we're building software for a bank account 218 00:10:17.279 --> 00:10:19.440 or an election system, we need a higher level of 219 00:10:19.440 --> 00:10:24.000 thinking than just passing around primitive numbers that might secretly overflow, which. 220 00:10:23.799 --> 00:10:27.639 Brings us directly to the architectural solution, which is data 221 00:10:27.639 --> 00:10:32.159 abstraction and object oriented programming or oop right. 222 00:10:32.120 --> 00:10:33.759 Object oriented programming. 223 00:10:34.000 --> 00:10:37.600 Basically, we stop treating the computer like a naive calculator 224 00:10:38.080 --> 00:10:40.799 and we start teaching it how to model reality. We 225 00:10:40.879 --> 00:10:43.519 use data abstraction to create abstract data. 226 00:10:43.240 --> 00:10:45.919 Types, and we define an object exactly. 227 00:10:45.519 --> 00:10:50.440 In the text notes. An object has three distinct properties, state, identity, 228 00:10:50.679 --> 00:10:51.320 and behavior. 229 00:10:51.600 --> 00:10:53.799 Let's try to ground this with a real world metaphor, 230 00:10:53.799 --> 00:10:56.559 because it gets pretty abstract. Sure, if a primitive integer 231 00:10:56.639 --> 00:10:59.720 is just like the role ingredients of a cake flour 232 00:10:59.799 --> 00:11:02.720 and sugar, an object is the fully baked. 233 00:11:02.480 --> 00:11:05.480 Cake, or to use a mechanical metaphor, if the primitive 234 00:11:05.519 --> 00:11:09.080 data is just a loose exposed AA battery, an object 235 00:11:09.120 --> 00:11:10.279 is a digital stopwatch. 236 00:11:10.559 --> 00:11:12.799 Oh I like that. So the battery the raw data 237 00:11:12.879 --> 00:11:15.639 is locked inside. Its state is whatever time is currently 238 00:11:15.639 --> 00:11:16.840 displayed on the screen right. 239 00:11:17.159 --> 00:11:20.759 Its identity is the literal physical stopwatch sitting in your hand, 240 00:11:21.080 --> 00:11:24.919 and its behavior represents the buttons on the outside start stop, reset. 241 00:11:25.080 --> 00:11:27.679 So the abstract data type, or the API as programmers 242 00:11:27.720 --> 00:11:29.919 call it, is basically the instruction manual or the menu. 243 00:11:30.279 --> 00:11:33.720 Yes, the API tells you exactly what the stopwatch does 244 00:11:33.759 --> 00:11:36.639 and which buttons to push, without requiring you to know 245 00:11:36.720 --> 00:11:39.480 how the battery connects to the circuit board inside. 246 00:11:39.600 --> 00:11:41.600 You don't need to know the recipe. You can't touch 247 00:11:41.639 --> 00:11:43.720 the battery directly at all. You can only interact with 248 00:11:43.799 --> 00:11:44.879 the buttons, and. 249 00:11:44.799 --> 00:11:47.919 The text has a very specific term for locking that 250 00:11:47.960 --> 00:11:50.279 battery away, encapsulation. 251 00:11:50.480 --> 00:11:51.200 Encapsulation. 252 00:11:51.440 --> 00:11:55.519 It is the defensive wall of modern programming. It means 253 00:11:55.679 --> 00:11:59.240 hiding the internal representation of data from the client code 254 00:11:59.240 --> 00:12:02.279 that is using it. You force the outside world to 255 00:12:02.320 --> 00:12:06.039 interact with the object only through approved behaviors, and. 256 00:12:06.000 --> 00:12:09.639 The text cites this incredible historical example to illustrate what 257 00:12:09.720 --> 00:12:13.039 happens when you fail to build that defensive wall. It 258 00:12:13.080 --> 00:12:15.639 was during the two thousand US presidential election. 259 00:12:15.480 --> 00:12:16.840 Right in Vallujah County, Florida. 260 00:12:16.960 --> 00:12:21.200 Yeah, an electronic voting machine registered negative sixteen twenty two 261 00:12:21.279 --> 00:12:22.279 votes for Al Gore. 262 00:12:22.679 --> 00:12:25.840 Now completely regardless of the politics here, we are just 263 00:12:25.879 --> 00:12:28.919 looking at this from a pure software architecture standpoint. 264 00:12:29.000 --> 00:12:31.759 Exactly, how does a tally mathematically count backward? 265 00:12:32.000 --> 00:12:36.399 It is the ultimate example of failed encapsulation. If you 266 00:12:36.480 --> 00:12:40.200 think about a counter object for an election, A properly 267 00:12:40.360 --> 00:12:43.840 architected voting counter should have only one approved behavior, right, 268 00:12:43.960 --> 00:12:46.120 an increment button that adds exactly one vote. 269 00:12:46.159 --> 00:12:48.679 It can only go up. But if the programmer simply 270 00:12:48.759 --> 00:12:51.639 used a primitive integer to store the votes and left 271 00:12:51.679 --> 00:12:55.600 it completely exposed. If they left the AA battery sitting 272 00:12:55.639 --> 00:12:58.759 out on the table instead of locking it in the stopwatch, then. 273 00:12:58.639 --> 00:13:02.159 Any outside glitch, memory corruption, or even a malicious actor 274 00:13:02.200 --> 00:13:05.879 could bypass the increment logic entirely. They could reach directly 275 00:13:05.919 --> 00:13:08.480 into the raw data and overwrite the tally with the 276 00:13:08.519 --> 00:13:09.240 negative number. 277 00:13:09.399 --> 00:13:09.919 Wow. 278 00:13:10.200 --> 00:13:13.919 Proper encapsulation ensures that the internal integer is heavily guarded 279 00:13:13.919 --> 00:13:17.120 as a private variable. The data maintains its integrity because 280 00:13:17.120 --> 00:13:19.159 the only way to alter it is through the heavily 281 00:13:19.200 --> 00:13:20.440 restricted public methods. 282 00:13:20.559 --> 00:13:23.360 Okay, so encapsulation builds this vault around our data. That 283 00:13:23.399 --> 00:13:26.000 makes sense, But reading further, I realize that creates a 284 00:13:26.000 --> 00:13:27.080 whole new vulnerability. 285 00:13:27.200 --> 00:13:27.480 Also. 286 00:13:27.840 --> 00:13:30.600 Well, if you have a massive software program and multiple 287 00:13:30.600 --> 00:13:32.720 different parts of the system need access to that vault, 288 00:13:33.320 --> 00:13:35.919 how does the computer keep track of who holds the key? 289 00:13:36.360 --> 00:13:39.919 Ah? Yes, that requires a big mental shift in how 290 00:13:40.000 --> 00:13:43.600 we understand variables and memory. There is a fundamental difference 291 00:13:43.600 --> 00:13:47.279 between passing a primitive value and passing an object. If 292 00:13:47.279 --> 00:13:49.440 you have a primitive integer variable let's call it A, 293 00:13:49.960 --> 00:13:52.679 and you set it to five, then you assign variable 294 00:13:52.720 --> 00:13:56.240 B to equal A, the computer physically cars out new 295 00:13:56.240 --> 00:13:59.480 memory and makes a brand new, independent copy of the 296 00:13:59.559 --> 00:14:00.000 number five. 297 00:14:00.320 --> 00:14:03.000 They are completely isolated from each other, exactly. 298 00:14:03.399 --> 00:14:05.559 Changing B to ten has zero effect on A. 299 00:14:05.720 --> 00:14:07.759 But with objects, it doesn't work that way. 300 00:14:08.039 --> 00:14:10.759 No, it does not. If you assign object A to 301 00:14:10.840 --> 00:14:13.840 object B, the computer does not copy the stopwatch. 302 00:14:13.919 --> 00:14:15.519 It doesn't copy the object itself. 303 00:14:15.759 --> 00:14:19.919 Right with objects, variables do not store the physical object itself. 304 00:14:20.320 --> 00:14:23.759 They store a reference to the object a memory address. Okay, 305 00:14:23.840 --> 00:14:26.360 so if you find variable A to variable B, you're 306 00:14:26.399 --> 00:14:29.720 literally just copying the address. Both A and B are 307 00:14:29.759 --> 00:14:32.639 now pointing to the exact same object in the computer's memory. 308 00:14:33.360 --> 00:14:34.480 The text refers to this. 309 00:14:34.399 --> 00:14:37.480 As aliasing aliasing, So it's kind of like giving two 310 00:14:37.559 --> 00:14:40.279 different people remote controls to the exact same television. 311 00:14:40.360 --> 00:14:41.559 That is a perfect analogy. 312 00:14:41.759 --> 00:14:44.960 If person A uses their remote to change the channel, 313 00:14:45.320 --> 00:14:48.559 person B is suddenly watching a different show, even if 314 00:14:48.559 --> 00:14:50.320 they didn't touch their own remote at all. 315 00:14:50.519 --> 00:14:53.600 And in large scale software development, that is a total 316 00:14:53.720 --> 00:14:54.600 nightmare scenario. 317 00:14:54.759 --> 00:14:56.159 I can imagine you might have. 318 00:14:56.039 --> 00:14:59.279 One developer working on a module that uses a specific 319 00:14:59.320 --> 00:15:03.360 data object, assuming they have a safe, independent copy, so 320 00:15:03.440 --> 00:15:05.919 they tweak the data for their specific. 321 00:15:05.440 --> 00:15:09.039 Feature, unknowingly changing the channel on a totally different developers 322 00:15:09.120 --> 00:15:12.320 module across the system because they were both holding references 323 00:15:12.320 --> 00:15:13.679 to the same memory address. 324 00:15:13.759 --> 00:15:18.240 It is a massive source of subtle cascading bugs. Understanding 325 00:15:18.279 --> 00:15:21.759 aliasing is really crucial for programmers, and it also brings 326 00:15:21.799 --> 00:15:23.600 up the issue of memory management. 327 00:15:23.799 --> 00:15:27.080 Right because what happens when a variable is reassigned to 328 00:15:27.080 --> 00:15:29.759 something else and an object is left with no references 329 00:15:29.799 --> 00:15:30.759 pointing to it at all. 330 00:15:31.200 --> 00:15:35.080 Exactly, say we throw away both TV remotes. The TV 331 00:15:35.240 --> 00:15:37.360 is still sitting there, taking up physical space in the 332 00:15:37.399 --> 00:15:40.080 living room, but nobody can ever interact with it again. 333 00:15:40.320 --> 00:15:42.519 The text calls this an orphaned object. 334 00:15:42.919 --> 00:15:46.799 Yes, and in older programming languages like C or C 335 00:15:46.919 --> 00:15:50.000 plus plus, the human developer actually had to write manual 336 00:15:50.039 --> 00:15:53.799 code to go find that abandoned TV and throw it 337 00:15:53.840 --> 00:15:54.399 in the dumpster. 338 00:15:54.600 --> 00:15:58.399 And knowing human fallibility, developers probably constantly forgot to write 339 00:15:58.399 --> 00:15:59.519 the cleanup code all. 340 00:15:59.440 --> 00:16:03.039 The time, those orphaned objects would sit in the RAM indefinitely, 341 00:16:04.799 --> 00:16:07.480 and this cause what we call memory leaks, where a 342 00:16:07.480 --> 00:16:11.159 program running for several days would slowly consume all the 343 00:16:11.159 --> 00:16:14.320 computer's available memory until the entire system. 344 00:16:14.039 --> 00:16:17.159 Just crashed, or I guess they would accidentally delete memory 345 00:16:17.200 --> 00:16:20.080 that another part of the program is still actively using. 346 00:16:19.879 --> 00:16:22.120 Which causes an immediate catastrophic failure. 347 00:16:22.200 --> 00:16:25.080 Yeah, so I'm assuming modern Java doesn't trust humans to 348 00:16:25.120 --> 00:16:26.080 handle this anymore. 349 00:16:26.159 --> 00:16:29.879 It definitely does not. Java introduced an automated system called 350 00:16:29.960 --> 00:16:30.799 garbage collection. 351 00:16:31.000 --> 00:16:32.559 Garbage collection, Yeah. 352 00:16:32.360 --> 00:16:35.759 It acts as this invisible, highly efficient custodian running in 353 00:16:35.799 --> 00:16:40.440 the background. It essentially traces the active reference trees starting 354 00:16:40.440 --> 00:16:43.080 from the core roots of the running program. It follows 355 00:16:43.159 --> 00:16:45.840 every active reference to see which objects are still. 356 00:16:45.639 --> 00:16:48.240 Reachable, like tracing the wiring in a house to see 357 00:16:48.240 --> 00:16:51.200 which outlets are actually connected to the breaker box exactly. 358 00:16:51.480 --> 00:16:54.360 Any object that cannot be reached by tracing those active 359 00:16:54.360 --> 00:16:58.759 wires is deemed an orphan. The garbage collector then performs 360 00:16:58.799 --> 00:17:02.240 a sweep automatic reclaiming the memory space used by those 361 00:17:02.399 --> 00:17:04.880 orphans and recycling it back into the system. 362 00:17:04.599 --> 00:17:07.079 Pool, so the programmer never has to write a single 363 00:17:07.160 --> 00:17:08.720 line of memory management code. 364 00:17:08.799 --> 00:17:09.160 None. 365 00:17:09.440 --> 00:17:12.920 That invisible automation is incredible for preventing memory leaks. But 366 00:17:13.000 --> 00:17:15.839 you know, we still haven't solved the remote control problem. Sure, 367 00:17:16.079 --> 00:17:18.960 garbage collection cleans up the abandoned TVs, but as long 368 00:17:19.000 --> 00:17:21.839 as a TV is active, aliasing means multiple remotes can 369 00:17:21.880 --> 00:17:25.000 still secretly change its channel. Is there a way to 370 00:17:25.000 --> 00:17:27.319 build data that just never changes so we don't have 371 00:17:27.359 --> 00:17:29.279 to stress about who holds a reference to it. 372 00:17:29.440 --> 00:17:34.240 Yes. The architectural solution to aliasing is immutability. Immutability and 373 00:17:34.319 --> 00:17:36.960 immutable data type is designed so that once the object 374 00:17:37.000 --> 00:17:41.000 is constructed in memory, its value can never ever be altered. 375 00:17:41.480 --> 00:17:44.880 In Java, a string of text is immutable, a date 376 00:17:44.920 --> 00:17:46.039 object is immutable. 377 00:17:46.319 --> 00:17:47.880 Wait. I have to push back on this a bit 378 00:17:47.960 --> 00:17:51.880 because it sounds horrifyingly inefficient for a system that's supposed 379 00:17:51.920 --> 00:17:55.599 to be obsessed with speed. How so, well, if I 380 00:17:55.680 --> 00:17:58.599 have an immutable date object set to Tuesday and I 381 00:17:58.680 --> 00:18:01.440 simply want to update it to way Wednesday, you're telling 382 00:18:01.519 --> 00:18:04.200 me I can't just change the day. The computer has 383 00:18:04.240 --> 00:18:07.799 to completely destroy the Tuesday object and build an entirely 384 00:18:07.880 --> 00:18:10.319 new Wednesday object in a new memory address. 385 00:18:10.599 --> 00:18:14.799 That is correct. Creating new objects constantly does incur performance cost, 386 00:18:15.880 --> 00:18:18.519 and it triggers the garbage collector more frequently to clean 387 00:18:18.599 --> 00:18:19.759 up the discarded Tuesday. 388 00:18:19.920 --> 00:18:22.599 That seems like a massive waste of processing power just 389 00:18:22.640 --> 00:18:24.119 to change one piece of data. 390 00:18:24.319 --> 00:18:27.319 It is a deliberate trade off. Programmers realize that the 391 00:18:27.319 --> 00:18:31.559 performance hit is entirely worth the architectural security. Immutable objects 392 00:18:31.559 --> 00:18:33.839 are exponentially safer in complex. 393 00:18:33.480 --> 00:18:35.480 Systems because they can't be changed. 394 00:18:35.200 --> 00:18:39.200 Right, especially when dealing with concurrent programming where multiple threads 395 00:18:39.200 --> 00:18:40.440 are running simultaneously. 396 00:18:40.720 --> 00:18:44.960 Ah okay. Because if a date object is physically incapable 397 00:18:45.000 --> 00:18:48.319 of changing, I don't care if fifty different modules have 398 00:18:48.440 --> 00:18:51.160 alias references to it. I don't have to worry about 399 00:18:51.160 --> 00:18:54.160 someone else's remote control changing my channel because the TV 400 00:18:54.359 --> 00:18:56.680 is permanently locked to one station. 401 00:18:56.680 --> 00:18:59.319