WEBVTT 1 00:00:00.120 --> 00:00:03.720 You know, there is this really profound, almost kind of 2 00:00:03.799 --> 00:00:05.320 unsettling concept in. 3 00:00:05.400 --> 00:00:08.759 Linguistics, Oh right, the idea that the language you use 4 00:00:08.839 --> 00:00:10.199 fundamentally limits. 5 00:00:09.880 --> 00:00:12.839 Your thoughts exactly. The theory argues that if you don't 6 00:00:12.839 --> 00:00:15.800 have the vocabulary or like the grammatical structure to describe 7 00:00:15.800 --> 00:00:18.600 a concept, you physically cannot conceptualize it. 8 00:00:18.760 --> 00:00:22.719 Yeah, you're basically trapped inside the borders of your own vocabulary. 9 00:00:22.800 --> 00:00:26.399 Right, And today's deep dive into Robert W. Sebesta's definitive 10 00:00:26.440 --> 00:00:31.079 text Concepts of Programming Languages takes that exact linguistic theory 11 00:00:31.320 --> 00:00:33.280 and applies it to the digital world. 12 00:00:33.079 --> 00:00:35.679 Which is such a fascinating lens to view this through. 13 00:00:35.840 --> 00:00:38.960 It really is. Our mission today is to decode, you know, 14 00:00:39.039 --> 00:00:41.679 why programming languages are built the way they are. We're 15 00:00:41.719 --> 00:00:43.920 going to look at the hidden trade offs their designers 16 00:00:44.000 --> 00:00:47.880 made and how these invisible architectures shape the modern digital 17 00:00:47.920 --> 00:00:50.520 infrastructure that you interact with every single day. 18 00:00:50.640 --> 00:00:53.479 Because looking at the blueprints of these languages, it reveals 19 00:00:53.520 --> 00:00:56.960 a lot about the hard physical constraints and the deeply 20 00:00:57.079 --> 00:01:02.399 human decisions that gave us everything from modern artificial intelligence 21 00:01:02.439 --> 00:01:04.519 to global banking systems. 22 00:01:04.920 --> 00:01:07.079 Yeah, and some of those decisions were brilliant and some 23 00:01:07.159 --> 00:01:09.680 were well, deeply flawed. 24 00:01:09.439 --> 00:01:13.480 Very flawed. But we aren't here to learn syntax, you know. 25 00:01:14.040 --> 00:01:17.359 We are analyzing the history of digital thought itself. 26 00:01:17.280 --> 00:01:20.840 Absolutely, But before we can even judge that history, we 27 00:01:20.959 --> 00:01:23.879 really have to understand the metrics, like what makes a 28 00:01:23.959 --> 00:01:25.400 language good or bad? 29 00:01:25.519 --> 00:01:26.359 Right, the criteria? 30 00:01:26.480 --> 00:01:29.760 Yeah, And the fascinating thing is how drastically those metrics 31 00:01:29.760 --> 00:01:33.439 shifted over time. If you look the nineteen fifties, a 32 00:01:33.560 --> 00:01:36.560 language was evaluated almost entirely on machine. 33 00:01:36.239 --> 00:01:39.959 Efficiency because the hardware was astronomically expensive back then, right, 34 00:01:40.000 --> 00:01:43.120 the computer cost millions and the programmers were relatively cheap. 35 00:01:43.439 --> 00:01:45.719 But by time we hit the nineteen seventies, the economists 36 00:01:45.760 --> 00:01:50.319 completely flipped. The evaluation became totally human centric. 37 00:01:50.480 --> 00:01:53.560 Yeah, it became all about readability and write ability because 38 00:01:53.599 --> 00:01:56.840 humans had to read it exactly. That shift was essentially 39 00:01:56.879 --> 00:02:00.519 an economic survival tactic. The software industry at a wall 40 00:02:00.519 --> 00:02:03.519 when they realize the life cycle of software isn't just 41 00:02:03.560 --> 00:02:05.400 about you know, writing code once. 42 00:02:05.200 --> 00:02:07.040 Right, You don't just write it and walk away. 43 00:02:07.079 --> 00:02:11.560 No, not at all. The massive hidden financial drain is maintenance. 44 00:02:12.360 --> 00:02:16.280 Sebesta's text highlights that for large systems with long lifetimes, 45 00:02:16.639 --> 00:02:19.680 maintenance costs often run two to four times higher than 46 00:02:19.680 --> 00:02:21.159 the initial development cost. 47 00:02:21.280 --> 00:02:23.919 Wow, two to four times Yeah. 48 00:02:23.520 --> 00:02:25.400 So I mean if you write a program that is 49 00:02:25.560 --> 00:02:29.280 mathematically efficient but impossible for a future human to decipher, 50 00:02:29.680 --> 00:02:32.719 it becomes an immense financial liability. 51 00:02:32.159 --> 00:02:36.039 Which brings up orthogonality. Oh yeah, a big one. It's 52 00:02:36.039 --> 00:02:38.840 a huge factor in whether a language is readable and writeable. 53 00:02:39.240 --> 00:02:41.840 But I'll admit it sounds like a terrifying math term. 54 00:02:41.919 --> 00:02:43.240 It does sound a bit intimidating. 55 00:02:43.319 --> 00:02:46.719 Okay, let's unpack this. Letn write an analogy. Worthogonality is 56 00:02:46.840 --> 00:02:51.080 like having a bucket of standard Lego bricks. I like that. 57 00:02:51.120 --> 00:02:53.879 You can build absolutely anything you want because every single 58 00:02:53.919 --> 00:02:56.199 brick clicks together perfectly with any other brick. 59 00:02:56.319 --> 00:02:57.280 Right, They're universal. 60 00:02:57.520 --> 00:02:59.960 Yeah. A lack of orthogonality, on the other hand, is 61 00:03:00.080 --> 00:03:03.599 like having a bunch of highly specific action figure accessories 62 00:03:03.599 --> 00:03:06.719 that only fit into the hands of one specific toy. 63 00:03:06.759 --> 00:03:09.479 And the cognitive load of that action figure approach is 64 00:03:09.560 --> 00:03:11.759 exactly what designers try to avoid. 65 00:03:11.759 --> 00:03:14.560 Because you have to memorize every single exception exactly. 66 00:03:15.080 --> 00:03:18.680 In language design, orthogonality means you have a relatively small 67 00:03:18.719 --> 00:03:21.439 set of primitive constructs that can be combined in a 68 00:03:21.520 --> 00:03:24.479 small number of consistent ways, So no surprises. 69 00:03:24.599 --> 00:03:24.800 Right. 70 00:03:25.479 --> 00:03:29.800 Critically, every possible combination is legal and meaningful. There are 71 00:03:29.840 --> 00:03:34.439 no weird exceptions to memorize. The text illustrates this beautifully 72 00:03:34.439 --> 00:03:36.759 by comparing early computer architectures. 73 00:03:36.840 --> 00:03:39.039 Oh, the Vax versus IBM example. 74 00:03:39.159 --> 00:03:43.400 Yeah, the Vax mini computer featured an orthogonal thirty two 75 00:03:43.479 --> 00:03:46.919 bit edition instruction. It allowed the operands to live in 76 00:03:46.960 --> 00:03:48.560 any combination of memory. 77 00:03:48.280 --> 00:03:50.560 Or registers, so it didn't matter where the data was. 78 00:03:50.800 --> 00:03:54.159 Exactly, the instruction executed the exact same way regardless. 79 00:03:54.319 --> 00:03:58.319 The consequence of the older IBM mainframe design, by contrast, 80 00:03:59.000 --> 00:04:01.960 was this mass of cognitive burden on the programmer. It 81 00:04:02.000 --> 00:04:03.360 is completely non orthogonal. 82 00:04:03.560 --> 00:04:07.000 It required entirely different instructions depending on where the data lived. 83 00:04:07.199 --> 00:04:09.879 Right, and certain combinations just weren't allowed at all. You 84 00:04:09.879 --> 00:04:13.479 spend half your time fighting the language's arbitrary rules instead 85 00:04:13.520 --> 00:04:16.079 of solving the actual problem. Yeah. 86 00:04:16.160 --> 00:04:19.319 But even if you have perfect orthogonality, you can still 87 00:04:19.399 --> 00:04:22.720 ruin a language's readability if you obscure the context. 88 00:04:22.920 --> 00:04:23.680 Oh. Absolutely. 89 00:04:23.720 --> 00:04:27.040 A perfect example of this is the Unix operating system. 90 00:04:27.439 --> 00:04:30.680 The command REP is famous for being incredibly powerful but 91 00:04:31.160 --> 00:04:32.720 totally baffling to look at. 92 00:04:33.000 --> 00:04:34.079 It just looks like a typo. 93 00:04:34.319 --> 00:04:36.680 It really does. The appearance of the word tells you 94 00:04:36.800 --> 00:04:39.519 nothing about its function. People just memorize it as a 95 00:04:39.519 --> 00:04:43.079 search tool, but its syntax is deeply tied to the 96 00:04:43.120 --> 00:04:45.680 context of a completely different, older tool. 97 00:04:45.800 --> 00:04:48.759 Right. It's an acronym born from the old Unix text 98 00:04:48.920 --> 00:04:52.160 editor EAD. To search for something globally, you type G, 99 00:04:52.600 --> 00:04:55.480 then the slash, then the regular expression you were looking for, 100 00:04:55.560 --> 00:04:57.759 another slash, and P for print. 101 00:04:58.040 --> 00:04:59.879 So g regular expression. 102 00:04:59.480 --> 00:05:02.560 P exactly GRIP. So if you don't know the history 103 00:05:02.560 --> 00:05:04.879 of a nineteen seventies text editor, the command just looks 104 00:05:04.879 --> 00:05:05.959 like random keystrokes. 105 00:05:06.000 --> 00:05:10.800 Because context dictates meaning, and beyond readability, there is reliability, 106 00:05:10.839 --> 00:05:14.759 which heavily depends on type checking, ensuring. 107 00:05:14.439 --> 00:05:17.600 The data being passed around actually matches what the program expects. 108 00:05:18.000 --> 00:05:22.160 Right, the original C language famously omitted parameter type checking. 109 00:05:22.759 --> 00:05:25.600 You could pass a floating point representation of a number 110 00:05:25.839 --> 00:05:28.680 into a function that was strictly expecting an integer. 111 00:05:28.439 --> 00:05:31.600 And because the bitstring format of a float is completely 112 00:05:31.639 --> 00:05:34.879 different from an integer at the machine level, the CPU 113 00:05:35.040 --> 00:05:37.879 just blindly reads those float bits as if they were 114 00:05:37.879 --> 00:05:38.399 an integer. 115 00:05:38.560 --> 00:05:42.120 It results in total untraceable garbage data. 116 00:05:42.800 --> 00:05:45.920 But there's a tension here that seems almost impossible to resolve. 117 00:05:46.519 --> 00:05:50.680 If you prioritize extreme readability and strict reliability, the code 118 00:05:50.680 --> 00:05:51.759 gets endlessly. 119 00:05:51.480 --> 00:05:53.160 Verbose, right, yes, very wordy. 120 00:05:53.240 --> 00:05:56.279 But if you try to make it highly expressive, I imagine 121 00:05:56.160 --> 00:05:58.519 you start losing the humans who have to maintain it. 122 00:05:58.759 --> 00:06:00.199 How do designers balance that? 123 00:06:00.600 --> 00:06:04.160 It is the defining trade off in language design. Prioritizing 124 00:06:04.199 --> 00:06:08.160 pure expressivity gives you a language like APL. APL incorporates 125 00:06:08.199 --> 00:06:11.680 an enormous number of highly powerful, specialized operators. You can 126 00:06:11.720 --> 00:06:15.639 execute a massive, complex matrix calculation in a single line. 127 00:06:15.439 --> 00:06:17.160 Of code, which sounds great on paper. 128 00:06:17.399 --> 00:06:20.360 It does, but the cost of that conciseness is that 129 00:06:20.399 --> 00:06:24.560 the code looks like alien hieroglyphics. Daniel McCracken, a prominent 130 00:06:24.560 --> 00:06:28.600 computer science author, once spent four hours deciphering a single 131 00:06:28.759 --> 00:06:32.120 four line APL program. Wait four hours for four live 132 00:06:32.279 --> 00:06:36.439 four hours. When code becomes that dense, readability basically drops 133 00:06:36.439 --> 00:06:36.920 to zero. 134 00:06:37.160 --> 00:06:39.959 That is wild. But you know, we keep evaluating these 135 00:06:40.040 --> 00:06:42.920 languages based on human readability. But humans aren't the ones 136 00:06:42.959 --> 00:06:43.920 executing the code. 137 00:06:44.040 --> 00:06:45.519 No, the machine is right. 138 00:06:45.920 --> 00:06:49.720 The physical hardware is a dictator here. It fundamentally forces 139 00:06:49.839 --> 00:06:53.079 software to look a certain way. Specifically because of the 140 00:06:53.639 --> 00:06:54.759 von Neuman bottleneck. 141 00:06:55.000 --> 00:06:57.959 Yeah, nearly all computers since the nineteen forties operate on 142 00:06:57.959 --> 00:07:02.120 the von Neumann architecture. The defining characteristic is that the 143 00:07:02.160 --> 00:07:05.759 memory where the data and instructions reside is physically separated 144 00:07:05.759 --> 00:07:08.600 from the CPU where the execution actually. 145 00:07:08.279 --> 00:07:10.959 Happens, and they are connected by a data bus exactly. 146 00:07:11.040 --> 00:07:13.959 So to visualize that bottleneck, it's like having a massive, 147 00:07:13.959 --> 00:07:16.879 sprawling library from memory full of all the data. Right. 148 00:07:17.639 --> 00:07:20.720 But the CPU is this genius speed reader locked in 149 00:07:20.720 --> 00:07:24.000 a completely separate room. The only way they can communicate 150 00:07:24.120 --> 00:07:26.519 is through a tiny, slow dumbwaiter. 151 00:07:26.680 --> 00:07:27.800 That's a great way to put it. 152 00:07:27.920 --> 00:07:30.279 To do any work, the speed reader have to request 153 00:07:30.279 --> 00:07:32.759 a specific book, wait for the dumbwaiter to bring it, 154 00:07:33.160 --> 00:07:36.319 read one line, send it back, request another book, and 155 00:07:36.360 --> 00:07:36.680 so on. 156 00:07:36.959 --> 00:07:39.839 And that fetch execute cycle is the heartbeat of the machine, 157 00:07:39.879 --> 00:07:44.240 and that dumbwaiter is the bottleneck. The genius of imperative 158 00:07:44.279 --> 00:07:48.519 programming languages like see Java and fortran is that they 159 00:07:48.560 --> 00:07:52.120 are direct software models of that physical hardware. 160 00:07:52.399 --> 00:07:54.839 So variables aren't just an abstract math concept. 161 00:07:54.959 --> 00:07:58.560 Now. Variables don't exist because they are conceptually elegant. They 162 00:07:58.600 --> 00:08:03.000 exist to directly models specific memory cells in that library. 163 00:08:02.720 --> 00:08:05.680 And the assignment statement, like saying exquos five, is literally 164 00:08:05.680 --> 00:08:09.199 just modeling the physical operation of moving data onto that 165 00:08:09.279 --> 00:08:10.759 dumbwaiter and dropping it into a. 166 00:08:10.680 --> 00:08:14.120 Specific cell precisely. And iterative loops exist for the exact 167 00:08:14.120 --> 00:08:18.199 same reason. On a von Numann machine, sequentially executing instructions 168 00:08:18.240 --> 00:08:20.680 located next to each other in memory and then branching 169 00:08:20.720 --> 00:08:23.399 back to repeat them is the absolute fastest way to 170 00:08:23.439 --> 00:08:24.160 process data. 171 00:08:24.480 --> 00:08:26.160 Okay, I have to push back on this a little 172 00:08:26.199 --> 00:08:29.120 because the implications are kind of wild. We're saying that 173 00:08:29.480 --> 00:08:34.759 the fundamental building blocks of modern programming variables, assignments, loops 174 00:08:35.320 --> 00:08:38.320 aren't necessarily the natural way for human brains to solve 175 00:08:38.399 --> 00:08:39.559 mathematical logic. 176 00:08:39.759 --> 00:08:40.240 That's right. 177 00:08:40.399 --> 00:08:43.159 They only exist because a guy in the nineteen forties 178 00:08:43.559 --> 00:08:47.000 decided to physically separate the processor from the memory to 179 00:08:47.080 --> 00:08:50.759 save on vacuum tubes. We are literally thinking in the 180 00:08:50.799 --> 00:08:53.080 shape of a mid century circuit board. 181 00:08:53.279 --> 00:08:56.120 If we connect this to the bigger picture, that hardware 182 00:08:56.200 --> 00:09:01.279 architecture completely dominated software design. There are all alternative paradigms 183 00:09:01.360 --> 00:09:05.200 like functional programming languages which calculate using mathematical functions without 184 00:09:05.240 --> 00:09:07.440 standard variables or assignment statements. 185 00:09:07.480 --> 00:09:09.080 But they aren't the default. No. 186 00:09:09.200 --> 00:09:13.159 They have historically struggled to achieve mainstream dominance because translating 187 00:09:13.200 --> 00:09:18.240 functional concepts onto imperative von Neuman hardware inherently introduces inefficiencies. 188 00:09:18.559 --> 00:09:20.399 The hardware prefers its own reflection. 189 00:09:20.919 --> 00:09:23.960 Man that is fascinating. Let's look at the pioneers who 190 00:09:24.000 --> 00:09:26.919 first tried to bridge the gap between human thought and 191 00:09:26.960 --> 00:09:30.879 that rigid hardware. The story essentially starts in nineteen forty 192 00:09:30.919 --> 00:09:34.799 five in a remote Bavarian village with Conrad. 193 00:09:34.519 --> 00:09:39.799 Zeus Zuusi's environment was uniquely isolating. His lab in Berlin 194 00:09:39.960 --> 00:09:43.480 was destroyed by Allied bombing, so he relocated to Hinterstein 195 00:09:43.559 --> 00:09:46.159 and worked without access to a functioning computer. 196 00:09:46.440 --> 00:09:49.039 Heeb no computer at all, none, and in. 197 00:09:48.919 --> 00:09:55.120 That isolation he invented plangcolicol, the very first programming language. 198 00:09:55.159 --> 00:09:58.440 And he didn't just build like a basic calculator language either. 199 00:09:58.919 --> 00:10:03.000 He designed advance data structures, including nested records, even wrote 200 00:10:03.039 --> 00:10:05.559 forty nine pages of algorithms to play chess in Plank 201 00:10:05.559 --> 00:10:07.519 cal core, which is incredible, and he wasn't even a 202 00:10:07.559 --> 00:10:09.320 chess expert. He was just utilizing the rules of the 203 00:10:09.320 --> 00:10:12.200 game to prove his language could handle complex conditional logic. 204 00:10:12.720 --> 00:10:16.159 He even implemented mathematical assertions to prove his code was correct, 205 00:10:16.360 --> 00:10:18.759 which is a feature you see in modern Java today. 206 00:10:18.919 --> 00:10:21.480 Yeah. The historical tragedy there is that his work remained 207 00:10:21.519 --> 00:10:23.440 unpublished until nineteen seventy two. 208 00:10:23.519 --> 00:10:25.120 Oh wow, so no one knew about. 209 00:10:24.879 --> 00:10:28.639 It, right, The computing world had to independently reinvent all 210 00:10:28.679 --> 00:10:33.080 of those concepts. Throughout the early nineteen fifties, developers relied 211 00:10:33.120 --> 00:10:36.159 on pseudocodes like short code and speed coding, and those 212 00:10:36.159 --> 00:10:40.840 were slow, right extremely slow. They were pure interpreters, essentially 213 00:10:40.879 --> 00:10:45.360 simulating hardware capabilities like floating point math that the physical 214 00:10:45.399 --> 00:10:49.519 machines lacked. Because the software was simulating non existent hardware, 215 00:10:49.559 --> 00:10:51.879 the execution was just agonizingly slow. 216 00:10:52.039 --> 00:10:54.879 But that dynamic shifted completely in nineteen fifty four with 217 00:10:54.919 --> 00:10:58.480 the IBM seven oh four. It finally included hardware support 218 00:10:58.480 --> 00:11:01.480 for floating point math, which remove the primary excuse for 219 00:11:01.600 --> 00:11:03.120 using slow interpreters, and. 220 00:11:03.039 --> 00:11:05.879 That hardware upgrade opened the door for John Bachis to 221 00:11:05.919 --> 00:11:07.039 invent Fortran. 222 00:11:06.759 --> 00:11:08.639 The first major compiled language. 223 00:11:08.759 --> 00:11:12.120 Yes, and the economic environment of the nineteen fifties dictated 224 00:11:12.120 --> 00:11:16.840 FORTRAN's entire design philosophy. Computers cost millions of dollars, while 225 00:11:16.879 --> 00:11:20.399 programmer salaries were a rounding error by comparison, so efficiency 226 00:11:20.480 --> 00:11:23.080 was king. The only metric that mattered was the raw 227 00:11:23.159 --> 00:11:27.720 execution speed of the compiled code. Bacchus's team dedicated the 228 00:11:27.840 --> 00:11:30.919 vast majority of their effort to writing an optimizing compiler 229 00:11:31.240 --> 00:11:36.639 capable of generating machine code that rivaled handwritten assembly language inefficiency. 230 00:11:37.000 --> 00:11:40.600 Here's where it gets really interesting, though. The original documentation 231 00:11:40.720 --> 00:11:45.399 for Fortran boldly claimed that the language would eliminate coding 232 00:11:45.519 --> 00:11:47.200 errors and the debugging process. 233 00:11:47.360 --> 00:11:49.960 Laughs. Yeah, that was incredibly optimistic. 234 00:11:50.039 --> 00:11:52.919 Obviously that didn't happen, but it's fascinating how that sheer 235 00:11:53.000 --> 00:11:58.240 optimism masked the brutal realities of early programming. Fortran I 236 00:11:58.279 --> 00:12:00.320 didn't even have independent compilation. 237 00:12:00.159 --> 00:12:02.639 Which was a massive operational hurdle. If you needed to 238 00:12:02.759 --> 00:12:05.200 change a single line of code, you had to recompile 239 00:12:05.240 --> 00:12:06.879 the entire program from scratch. 240 00:12:06.960 --> 00:12:09.960 And those early vacuum tube machines were incredibly prone to 241 00:12:10.000 --> 00:12:10.759 hardware films. 242 00:12:10.799 --> 00:12:14.519 Oh they crashed constantly, so compiling a large program was 243 00:12:14.559 --> 00:12:18.279 basically a race against the machine crashing. You practically couldn't 244 00:12:18.279 --> 00:12:20.480 write a program longer than three hundred or four hundred 245 00:12:20.559 --> 00:12:23.799 lines because the computer would fail before the compiler finished. 246 00:12:23.960 --> 00:12:27.960 That sounds like a nightmare. Despite those limitations, though, proving 247 00:12:28.000 --> 00:12:30.879 that a high level language could be compiled into efficient 248 00:12:30.960 --> 00:12:36.639 machine code changed everything. Fortran became the lingua franca of computing. 249 00:12:36.960 --> 00:12:40.279 It did, but it was built by scientists for scientists 250 00:12:40.320 --> 00:12:44.039 to do heavy math. As the nineteen fifties closed, divergent 251 00:12:44.080 --> 00:12:48.279 evolution took hold, people needed computers to handle completely different domains, 252 00:12:48.559 --> 00:12:51.480 leading to two massive new languages in nineteen fifty nine, 253 00:12:52.039 --> 00:12:53.679 Lisp and cobl Right. 254 00:12:53.799 --> 00:12:56.879 So John McCarthy at MIT needed a language for the 255 00:12:56.960 --> 00:12:59.759 nascent field of artificial intelligence. 256 00:12:59.159 --> 00:13:02.600 Which is completely different from calculating missile trajectories exactly. 257 00:13:02.840 --> 00:13:06.960 AI didn't require number crunching, it required symbolic computation. It 258 00:13:07.000 --> 00:13:11.559 needed to manipulate words, logic, and abstract concepts. So McCarthy 259 00:13:11.600 --> 00:13:14.840 created Lisp, moving away from standard variables and loops in 260 00:13:14.960 --> 00:13:16.919 favor of linked lists and recursion. 261 00:13:17.120 --> 00:13:19.759 The syntax is famously jarring to look at, though it's 262 00:13:19.799 --> 00:13:21.759 just endless nested parentheses. 263 00:13:21.840 --> 00:13:23.039 It takes some getting used to. 264 00:13:23.200 --> 00:13:27.279 But the underlying mechanism is brilliant. In pure Lisp, the 265 00:13:27.320 --> 00:13:30.320 code and the data share the exact same structural format. 266 00:13:31.080 --> 00:13:33.200 A list can represent a simple set of data, or 267 00:13:33.240 --> 00:13:36.519 it can represent an abstract syntax tree like a function 268 00:13:36.639 --> 00:13:37.399 you execute. 269 00:13:37.559 --> 00:13:41.720 And that property homochinicity means a list program can treat 270 00:13:41.720 --> 00:13:45.279 its own code as data, modifying and rewriting itself on. 271 00:13:45.240 --> 00:13:47.799 The fly, which is mind blowing for nineteen fifty nine. 272 00:13:47.879 --> 00:13:51.120 It really is. That parody is precisely why it became 273 00:13:51.159 --> 00:13:55.399 the foundational language for early AI research. Meanwhile, across the aisle, 274 00:13:55.519 --> 00:13:57.720 the business world had entirely different. 275 00:13:57.440 --> 00:14:01.600 Requirements, right they needed to process payrolls, trek inventory format 276 00:14:01.639 --> 00:14:02.519 accounting reports. 277 00:14:02.639 --> 00:14:06.279 Grace Happer laid the conceptual groundwork there with phlomatic, proving 278 00:14:06.320 --> 00:14:11.440 computers could be programmed using English keywords rather than mathematical symbols, which. 279 00:14:11.279 --> 00:14:14.159 Directly paved the way for cobl. And you know, computer 280 00:14:14.200 --> 00:14:16.480 scientist seem to look down on cobol because it's highly 281 00:14:16.559 --> 00:14:20.120 verbose and lacks mathematical elegance, but looking at the domain 282 00:14:20.200 --> 00:14:22.960 it was built for, if it runs the global banking system, 283 00:14:23.000 --> 00:14:26.840 and handled decimals perfectly. Isn't that a massive design success? 284 00:14:27.080 --> 00:14:31.120 I completely agree it was a huge success. Kobol's real 285 00:14:31.240 --> 00:14:36.080 architectural triumph was its data division. It introduced hierarchical data 286 00:14:36.120 --> 00:14:39.679 structures and allowed variable names up to thirty characters long, 287 00:14:39.799 --> 00:14:41.360 complete with hyphens, so. 288 00:14:41.279 --> 00:14:43.159 You could name a variable year to. 289 00:14:43.159 --> 00:14:47.799 Date tex exactly. That was revolutionary for business logic. It 290 00:14:47.879 --> 00:14:50.799 allowed accountants and managers to actually read the structure of 291 00:14:50.840 --> 00:14:54.519 the data. And the sheer scale of its adoption is staggering. 292 00:14:54.120 --> 00:14:55.879 Because the Department of Defense mandated it. 293 00:14:55.960 --> 00:14:59.879 Yes, they forced it into existence, and it embedded its 294 00:15:00.080 --> 00:15:04.200 self into the world's infrastructure. During the Y two K preparations, 295 00:15:04.720 --> 00:15:08.000 estimate showed eight hundred million lines of COBAL were still 296 00:15:08.039 --> 00:15:10.480 actively running in just the twenty two square miles of 297 00:15:10.480 --> 00:15:12.720 Manhattan alone, just in Manhattan. That's in Manhattan. 298 00:15:12.720 --> 00:15:15.360 So by the early nineteen sixties, the computing landscape was 299 00:15:15.399 --> 00:15:19.159 totally fractured. You have the fourtran tribe doing scientific calculations 300 00:15:19.240 --> 00:15:22.840 and the Cobal tribe handling business administration. Naturally, the industry 301 00:15:22.840 --> 00:15:26.080 decided this was inefficient and attempted to forge one universal 302 00:15:26.120 --> 00:15:27.120 language to rule them all. 303 00:15:27.279 --> 00:15:29.759 And those unification efforts resulted in some of the most 304 00:15:29.799 --> 00:15:31.919 dramatic failures and software engineering. 305 00:15:32.080 --> 00:15:35.200 Yeah. The first major attempt was ALGL sixty, created by 306 00:15:35.200 --> 00:15:37.320 a joint European and American committee right. 307 00:15:37.279 --> 00:15:41.279 Yes, motivated largely by a shared fear of IBM dominating 308 00:15:41.360 --> 00:15:46.960 the industry. ALGAEOL sixty was conceptually brilliant. It introduced block structures, 309 00:15:47.000 --> 00:15:49.759 which fundamentally changed how variables were managed. 310 00:15:50.000 --> 00:15:52.480 Right. Instead of a variable being global, where changing X 311 00:15:52.519 --> 00:15:55.679 in one part of the program accidentally changes x everywhere else, 312 00:15:56.080 --> 00:16:00.360 causing absolute chaos, block structures essentially allowed program is to 313 00:16:00.360 --> 00:16:02.480 build fenced in yards for their data. 314 00:16:02.519 --> 00:16:04.720 Fencedin yards is a perfect way to describe it. 315 00:16:04.799 --> 00:16:08.120 A variable could exist entirely locally within a specific block 316 00:16:08.159 --> 00:16:11.279 of code and then just disappear when the block finished executing. 317 00:16:11.720 --> 00:16:15.360 ALGL was also the first language formally described by BNF 318 00:16:15.679 --> 00:16:17.000 backus NARFM. 319 00:16:16.840 --> 00:16:19.320 And BNF was a huge breakthrough because it provided a 320 00:16:19.320 --> 00:16:22.879 formal metal language to define the exact syntax grammar of 321 00:16:22.919 --> 00:16:26.480 a programming language. It's much like diagramming a complex sentence 322 00:16:26.480 --> 00:16:30.120 in linguistics. It removed the ambiguity from language specification. 323 00:16:30.279 --> 00:16:32.080 So it's a brilliant, but it fail in the US, 324 00:16:32.159 --> 00:16:33.080 right it did. 325 00:16:33.320 --> 00:16:37.039 Despite these innovations, Algaeoli failed to achieve widespread adoption in 326 00:16:37.080 --> 00:16:40.399 the US because it lacked standardized input and output statements. 327 00:16:40.639 --> 00:16:43.000 They didn't standardize how data goes in and out. 328 00:16:43.519 --> 00:16:48.399 No, the designers considered IO two machine dependent to standardize. Consequently, 329 00:16:48.559 --> 00:16:52.240 moving an Algaol program from one computer to another required 330 00:16:52.399 --> 00:16:55.120 rewriting the data handling code entirely. 331 00:16:55.440 --> 00:16:58.480 That's a deal breaker. The second major unification attempt came 332 00:16:58.480 --> 00:17:01.759 from IBM with their System three sixty. They wanted to 333 00:17:01.799 --> 00:17:04.599 sell a single hardware architecture to both the scientific and 334 00:17:04.640 --> 00:17:07.440 business markets, so they tried to build the ultimate software 335 00:17:07.480 --> 00:17:09.200 Swiss Army Knife PLI. 336 00:17:09.359 --> 00:17:12.440 They attempted to mash together four trans ross speed, Kobol's 337 00:17:12.440 --> 00:17:15.640 complex data structures, and Algel's block. 338 00:17:15.400 --> 00:17:17.920 Structure, and then they bolted on twenty three different exception 339 00:17:17.960 --> 00:17:22.119 handlers and extensive concurrency features. It was an everything bagel 340 00:17:22.480 --> 00:17:25.279 that basically gave the industry indigestion. It tried to be 341 00:17:25.319 --> 00:17:27.400 everything to everyone and became too heavy to lift. 342 00:17:27.680 --> 00:17:31.119 This raises an important question, how do we keep our 343 00:17:31.160 --> 00:17:36.240 tools from escaping our intellectual control. The legendary computer scientist 344 00:17:36.480 --> 00:17:41.880 Edsgardistras severely criticized PLI, stating that its sheer baroqueness escaped 345 00:17:41.880 --> 00:17:43.119 our intellectual control. 346 00:17:43.440 --> 00:17:46.400 Sheer baroquness. That's brutal, but true. 347 00:17:46.640 --> 00:17:51.039 When a language incorporates every conceivable paradigm, the feature interactions 348 00:17:51.079 --> 00:17:55.440 become hopelessly complex. A programmer using one subset of the 349 00:17:55.519 --> 00:17:59.839 language might trigger entirely unpredictable bugs because those features interact 350 00:17:59.839 --> 00:18:02.599 in visibly with another subset they don't even understand. 351 00:18:02.799 --> 00:18:05.559 It's like designing an airplane cockpit where turning on the 352 00:18:05.599 --> 00:18:08.680 windshield wipers might accidentally fire the thrusters because the wiring 353 00:18:08.720 --> 00:18:11.480 is just too dense to track exactly. So if the 354 00:18:11.559 --> 00:18:14.720 universal Swiss army knife approach collapsed under its own weight, 355 00:18:15.359 --> 00:18:18.920 how did language design evolve to manage the explosive complexity 356 00:18:18.960 --> 00:18:20.400 of modern software systems. 357 00:18:20.519 --> 00:18:23.960 Well, the industry realized they needed specialized paradigms, not an 358 00:18:24.079 --> 00:18:28.279 endless accumulation of features. A perfect illustration is Simulus sixty. 359 00:18:27.960 --> 00:18:30.200 Seven, developed in Norway, right yes. 360 00:18:30.400 --> 00:18:35.480 By Kristin Nigard and Olohandal. They were building system simulations 361 00:18:35.559 --> 00:18:38.359 like modeling the traffic of hundreds of independent ships in 362 00:18:38.400 --> 00:18:38.759 a port. 363 00:18:38.920 --> 00:18:41.400 Oh wow, that sounds complicated. 364 00:18:40.960 --> 00:18:44.519 It is, Using traditional procedural code to track the individual 365 00:18:44.519 --> 00:18:48.000 state of every single ship is a logistical nightmare. They 366 00:18:48.000 --> 00:18:51.880 needed subprograms that could pause their execution, retain their state, 367 00:18:52.000 --> 00:18:53.160 and resume later. 368 00:18:53.079 --> 00:18:55.000 What we call corotines today, right. 369 00:18:55.440 --> 00:18:58.880 And by trying to solve that highly specific simulation problem, 370 00:18:58.920 --> 00:19:01.160 they realized they needed to bind the data like the 371 00:19:01.200 --> 00:19:05.119 ship's tonnage its destination, together with the functions like sailing 372 00:19:05.559 --> 00:19:09.119 docking into a single independent, simulated entity, And. 373 00:19:09.079 --> 00:19:13.359 In doing so they accidentally invented classes and data abstraction. 374 00:19:13.519 --> 00:19:15.759 They birthed object oriented programming. 375 00:19:15.880 --> 00:19:18.880 It was a massive paradigm shift derived entirely from a 376 00:19:18.920 --> 00:19:21.839 practical requirement. Around the same time, in nineteen seventy one, 377 00:19:22.160 --> 00:19:27.799 Nicholasworth introduced PASCAL, designed explicitly for teaching. Pascal completely rejected 378 00:19:27.839 --> 00:19:32.599 the PLI philosophy of infinite features. It prioritized simplicity, expressivity, 379 00:19:32.599 --> 00:19:35.759 and safety, which allowed it to dominate university computer science 380 00:19:35.759 --> 00:19:37.079 departments for two decades. 381 00:19:37.480 --> 00:19:41.200 Then, in nineteen seventy two, Dennis Ritchie at Bell Labs 382 00:19:41.240 --> 00:19:45.279 created c It was designed for systems programming, specifically to 383 00:19:45.279 --> 00:19:50.160 write the Unix operating system Seagay programmers high level structural tools, 384 00:19:50.400 --> 00:19:53.839 but retained the ability to manipulate raw memory addresses like 385 00:19:53.880 --> 00:19:54.960 an assembly language. 386 00:19:55.000 --> 00:19:58.559 But to achieve that power, Richie intentionally left out strict 387 00:19:58.680 --> 00:20:00.319 type checking was. 388 00:20:00.240 --> 00:20:04.400 Built for systems programmers who inherently needed to bypass rigid 389 00:20:04.480 --> 00:20:08.559 data rules to interface directly with hardware. The language trust 390 00:20:08.599 --> 00:20:09.960 the programmer implicitly. 391 00:20:10.039 --> 00:20:13.279 It provides incredible execution speed and power, but the tradeoff 392 00:20:13.400 --> 00:20:16.799 is a massive surface area for security vulnerabilities and memory 393 00:20:16.839 --> 00:20:19.079 leaks if the programmer makes a mistake. 394 00:20:18.960 --> 00:20:22.599 Which brings us to the ultimate counter approach ADA. By 395 00:20:22.640 --> 00:20:25.319 the late nineteen seventies, the Department of Defense realized they 396 00:20:25.319 --> 00:20:28.640 were actively maintaining over four hundred and fifty different programming 397 00:20:28.680 --> 00:20:30.559 languages across their embedded system. 398 00:20:30.599 --> 00:20:34.160 Four hundred and fifty languages. It was an unsustainable logistical nightmare. 399 00:20:34.200 --> 00:20:37.680 So they launched a massive, rigorous international competition to develop 400 00:20:37.720 --> 00:20:40.319 a single, ultra reliable language. 401 00:20:39.920 --> 00:20:42.759