WEBVTT 00:00:00.000 --> 00:00:02.740 Welcome back to the Deep Dive. Today we are plumbing 00:00:02.740 --> 00:00:05.919 the depths of modern software architecture, looking 00:00:05.919 --> 00:00:08.179 at a name that, you know, while it might not 00:00:08.179 --> 00:00:10.599 be instantly recognizable outside of computer 00:00:10.599 --> 00:00:14.000 science circles, is responsible for the invisible, 00:00:14.179 --> 00:00:16.839 reliable structure of the digital world you interact 00:00:16.839 --> 00:00:19.809 with every single day. That's right. We are talking 00:00:19.809 --> 00:00:22.370 about Barbara Liskov. We are. And if you've ever 00:00:22.370 --> 00:00:26.429 written a line of code in, say, Java, C++, C 00:00:26.429 --> 00:00:29.890 Sharp, or, well, really any modern object -oriented 00:00:29.890 --> 00:00:31.809 language, you're standing directly on the foundation 00:00:31.809 --> 00:00:34.369 she helped pour. That's a powerful way to put 00:00:34.369 --> 00:00:37.149 it. It's true. She is, quite simply, one of the 00:00:37.149 --> 00:00:39.750 primary architects of reliable, reusable code. 00:00:40.009 --> 00:00:43.009 She provided the... The theoretical rigor that 00:00:43.009 --> 00:00:45.409 turned programming from a kind of art into a 00:00:45.409 --> 00:00:47.469 reliable engineering discipline. So we've taken 00:00:47.469 --> 00:00:49.609 a stack of sources, chiefly material, detailing 00:00:49.609 --> 00:00:52.170 her really extensive career, her landmark projects 00:00:52.170 --> 00:00:55.469 at MIT, and the just staggering array of awards 00:00:55.469 --> 00:00:57.109 she's accumulated. And we're using that as our 00:00:57.109 --> 00:00:59.829 map. Right. We are here not just to list her 00:00:59.829 --> 00:01:01.570 achievements, but to understand the profound 00:01:01.570 --> 00:01:04.689 why behind them. And that's our mission today. 00:01:05.049 --> 00:01:07.549 We want to connect the abstract theoretical work 00:01:07.549 --> 00:01:09.890 she championed. And some of these concepts sound 00:01:09.890 --> 00:01:12.989 intimidating, like data abstraction or Byzantine 00:01:12.989 --> 00:01:15.510 fault tolerance. Yeah, they do. And connect them 00:01:15.510 --> 00:01:18.349 to their concrete practical impact on systems 00:01:18.349 --> 00:01:20.829 you rely on every day. We want to understand 00:01:20.829 --> 00:01:24.310 not just what she did, but how her rules ensure 00:01:24.310 --> 00:01:26.989 that the complex programs running cloud infrastructure, 00:01:27.329 --> 00:01:30.650 financial systems, and mobile apps don't just 00:01:30.650 --> 00:01:33.819 constantly break down. And when we look at her 00:01:33.819 --> 00:01:36.280 overall contribution, which spans, what, five 00:01:36.280 --> 00:01:39.480 decades, it really seems to stand on two massive 00:01:39.480 --> 00:01:42.079 complementary pillars. It does. First, there's 00:01:42.079 --> 00:01:43.879 the principle of data abstraction, which she 00:01:43.879 --> 00:01:46.239 formalized through abstract data types and the 00:01:46.239 --> 00:01:48.939 CLU language. And this, I mean, this fundamentally 00:01:48.939 --> 00:01:51.140 changed how we organize code at the component 00:01:51.140 --> 00:01:53.920 level. And second, there's the Liskov substitution 00:01:53.920 --> 00:01:57.120 principle, or LSP. This is the formal rule she 00:01:57.120 --> 00:01:59.659 developed for object -oriented programming that 00:01:59.659 --> 00:02:01.719 defines how different parts of a software system 00:02:01.769 --> 00:02:05.769 specifically parent child objects must relate 00:02:05.769 --> 00:02:08.490 to interact reliably which ensures that reusable 00:02:08.490 --> 00:02:12.370 code truly is reusable exactly and robust across 00:02:12.370 --> 00:02:14.689 different implementations right you put those 00:02:14.689 --> 00:02:17.169 two concepts together and they provide the structural 00:02:17.169 --> 00:02:20.409 integrity for well for the entire modern software 00:02:20.409 --> 00:02:22.889 industry okay let's unpack this starting with 00:02:22.889 --> 00:02:25.169 the path she took to the highest ranks of computing 00:02:25.169 --> 00:02:27.469 which I mean that itself is a story of intense 00:02:27.469 --> 00:02:30.889 focus and breaking institutional barriers we 00:02:30.990 --> 00:02:34.310 can start in Los Angeles. Barbara Liskoff, born 00:02:34.310 --> 00:02:37.150 Barbara Jane Huberman, arrived on the scene November 00:02:37.150 --> 00:02:40.949 7, 1939. She was the eldest of four children. 00:02:41.090 --> 00:02:43.289 And like a lot of early computer science pioneers, 00:02:43.550 --> 00:02:46.250 her story really starts in math. It does, firmly 00:02:46.250 --> 00:02:48.710 in the field of mathematics. But the context 00:02:48.710 --> 00:02:51.490 of her learning environment is absolutely critical 00:02:51.490 --> 00:02:53.509 to understanding the challenge she overcame. 00:02:53.729 --> 00:02:55.550 She got her bachelor's degree in mathematics 00:02:55.550 --> 00:02:57.629 from the University of California, Berkeley in 00:02:57.629 --> 00:03:01.110 1961 with a minor in physics. And the sources 00:03:01.110 --> 00:03:03.229 highlight a really stunning detail about that 00:03:03.229 --> 00:03:06.000 time. What's that? she had only one other female 00:03:06.000 --> 00:03:09.360 classmate in her major one one that's not just 00:03:09.360 --> 00:03:12.400 low representation it illustrates a deeply deeply 00:03:12.400 --> 00:03:14.900 isolated educational landscape for women who 00:03:14.900 --> 00:03:17.139 are pursuing technical fields back then that 00:03:17.139 --> 00:03:19.699 statistic isn't just an anecdote It reflects 00:03:19.699 --> 00:03:22.280 a systemic reality. I mean, she was operating 00:03:22.280 --> 00:03:25.039 in an environment that was, for all intents and 00:03:25.039 --> 00:03:27.620 purposes, designed to exclude her. And the challenges 00:03:27.620 --> 00:03:29.740 weren't just about, you know, being in the classroom. 00:03:29.800 --> 00:03:32.419 They were actual institutional roadblocks embedded 00:03:32.419 --> 00:03:35.199 right in the higher education system. Which brings 00:03:35.199 --> 00:03:38.259 us to a specific, almost unbelievable historical 00:03:38.259 --> 00:03:41.159 constraint she ran into when she was applying 00:03:41.159 --> 00:03:44.039 for grad school right after Berkeley. The Princeton 00:03:44.039 --> 00:03:47.000 hurdle. Exactly. The Princeton hurdle. Liskov 00:03:47.000 --> 00:03:49.240 applied to top graduate mathematics programs, 00:03:49.479 --> 00:03:52.819 including Berkeley and Princeton. But the source 00:03:52.819 --> 00:03:55.919 material reveals a stunning reality. Princeton 00:03:55.919 --> 00:03:58.240 University was institutionally not accepting 00:03:58.240 --> 00:04:00.379 female students in its mathematics program at 00:04:00.379 --> 00:04:02.240 the time she applied. It was an outright ban. 00:04:02.479 --> 00:04:04.979 An outright ban. Think about that for a moment. 00:04:05.039 --> 00:04:08.460 You have a highly capable, driven, future Turing 00:04:08.460 --> 00:04:11.740 Award winner literally barred from a top program 00:04:11.740 --> 00:04:14.599 simply because of her gender. It's just astounding. 00:04:14.620 --> 00:04:16.819 It wasn't about her qualifications. Not at all. 00:04:16.879 --> 00:04:19.800 It was a deeply embedded historical exclusion. 00:04:20.819 --> 00:04:23.180 The sheer intellectual caliber that was being 00:04:23.180 --> 00:04:26.040 rejected by institutional policy is, well, it's 00:04:26.040 --> 00:04:28.899 mind boggling. So that forced a pretty significant 00:04:28.899 --> 00:04:32.350 pivot for her. It did. And perhaps ironically, 00:04:32.569 --> 00:04:34.370 it led her directly into the burgeoning field 00:04:34.370 --> 00:04:36.689 of computing. Instead of pursuing theoretical 00:04:36.689 --> 00:04:39.550 math right away, she moved to Boston. And she 00:04:39.550 --> 00:04:41.990 secured her first professional role at the MITRE 00:04:41.990 --> 00:04:44.189 Corporation, where she worked for about a year. 00:04:44.490 --> 00:04:46.850 And that exposure to practical systems development 00:04:46.850 --> 00:04:50.850 was transformative for her. And after MITRE, 00:04:50.850 --> 00:04:53.600 she took a programming job at Harvard. Focusing 00:04:53.600 --> 00:04:55.660 on language translation. Yes, and it was in these 00:04:55.660 --> 00:04:57.939 professional roles, working directly with machines 00:04:57.939 --> 00:05:01.420 and code, that her intellectual path really solidified. 00:05:01.620 --> 00:05:04.360 She recognized that her mathematical mind could 00:05:04.360 --> 00:05:07.160 be applied with immense power to this new field 00:05:07.160 --> 00:05:09.180 of computer science. A field that was, you know, 00:05:09.199 --> 00:05:11.860 way more open and dynamic than the ossified mathematics 00:05:11.860 --> 00:05:14.000 departments of the time. And that strategic pivot 00:05:14.000 --> 00:05:16.300 was a success. She applied again to graduate 00:05:16.300 --> 00:05:18.980 programs, and she received her Ph .D. from Stanford 00:05:18.980 --> 00:05:22.220 University in March 1968. And this achievement 00:05:22.220 --> 00:05:25.939 is historically monumental. Oh, absolutely. She 00:05:25.939 --> 00:05:28.139 was one of the first women in the entire United 00:05:28.139 --> 00:05:31.060 States to be awarded a Ph .D. from a computer 00:05:31.060 --> 00:05:33.439 science department. It's a landmark achievement 00:05:33.439 --> 00:05:35.680 for her personally and really for everyone who 00:05:35.680 --> 00:05:38.620 followed. And of course, that path led her to 00:05:38.620 --> 00:05:41.060 become only the second woman after Frances Allen 00:05:41.060 --> 00:05:44.120 to receive the prestigious A .M. Turing Award. 00:05:44.680 --> 00:05:46.759 Her doctoral work at Stanford was supported by 00:05:46.759 --> 00:05:48.600 John McCarthy, one of the founders of artificial 00:05:48.600 --> 00:05:51.540 intelligence. Right. Her thesis was titled, A 00:05:51.540 --> 00:05:55.259 Program to Play Chess and Games. Now, this wasn't 00:05:55.259 --> 00:05:57.579 about building a full chess engine. That was 00:05:57.579 --> 00:05:59.459 way too computationally expensive back then. 00:05:59.519 --> 00:06:01.860 So it was more focused. Much more focused. It 00:06:01.860 --> 00:06:04.540 was about solving incredibly complex, specific 00:06:04.540 --> 00:06:07.579 scenarios at the very end of a chess game. And 00:06:07.579 --> 00:06:10.120 in that thesis, she introduced a really important 00:06:10.120 --> 00:06:13.720 concept that I think speaks to her focus on efficiency, 00:06:14.279 --> 00:06:17.100 the killer heuristic. We can't just drop that 00:06:17.100 --> 00:06:19.500 term without explaining it. No, we can't. What 00:06:19.500 --> 00:06:22.379 did the killer heuristic do and why was it so 00:06:22.379 --> 00:06:25.779 vital for early AI? The killer heuristic is essentially 00:06:25.779 --> 00:06:29.740 a memory trick. In AI search algorithms, like 00:06:29.740 --> 00:06:32.079 the ones used for chess, the computer explores 00:06:32.079 --> 00:06:35.000 millions of possible future moves. A huge decision 00:06:35.000 --> 00:06:38.790 tree. A massive one. And if a move causes a brilliant 00:06:38.790 --> 00:06:41.610 response that immediately refutes the current 00:06:41.610 --> 00:06:44.610 line of play, that killer move, the heuristic 00:06:44.610 --> 00:06:47.230 says you should remember that move and check 00:06:47.230 --> 00:06:49.569 it early in other branches of the search tree. 00:06:49.730 --> 00:06:51.610 Oh, interesting. Even if those other branches 00:06:51.610 --> 00:06:53.689 seem totally unrelated. Exactly. It's a way of 00:06:53.689 --> 00:06:55.990 saying, hey, if this move was really good or 00:06:55.990 --> 00:06:57.810 really bad over there, it might be good or bad 00:06:57.810 --> 00:07:00.290 over here, too. So test it first. And that lets 00:07:00.290 --> 00:07:03.050 you prune the search space, cut off entire branches 00:07:03.050 --> 00:07:05.750 of that tree early. Dramatically improves efficiency. 00:07:06.410 --> 00:07:09.470 It shows that from the very beginning, Liskov's 00:07:09.470 --> 00:07:12.230 research was focused on creating efficient, clear, 00:07:12.410 --> 00:07:15.290 and powerful ways for programs to handle complexity. 00:07:15.899 --> 00:07:18.220 It really set the intellectual stage for her 00:07:18.220 --> 00:07:21.439 later focus on robust program design and modularity. 00:07:21.500 --> 00:07:23.500 That's a fascinating intellectual trajectory. 00:07:23.720 --> 00:07:26.319 She went from optimizing decisions in a highly 00:07:26.319 --> 00:07:30.220 abstract game to optimizing the fundamental structure 00:07:30.220 --> 00:07:32.980 of all software. And that intellectual momentum 00:07:32.980 --> 00:07:35.360 carried her to the Massachusetts Institute of 00:07:35.360 --> 00:07:38.100 Technology, MIT, where she became an institute 00:07:38.100 --> 00:07:40.240 professor and a Ford professor of engineering. 00:07:40.560 --> 00:07:43.839 The move to MIT defined her professional life. 00:07:44.269 --> 00:07:46.709 and this is where she turned her focus to the 00:07:46.709 --> 00:07:49.779 driving problem of the 1970s. The increasing 00:07:49.779 --> 00:07:52.279 complexity of software. The inevitable spaghetti 00:07:52.279 --> 00:07:54.860 code. The spaghetti code that resulted from that 00:07:54.860 --> 00:07:57.459 complexity, which was unreliable, difficult to 00:07:57.459 --> 00:08:00.800 test, and virtually impossible to modify without 00:08:00.800 --> 00:08:03.339 introducing a whole new set of errors. It seems 00:08:03.339 --> 00:08:05.600 like early programming was so procedural, you 00:08:05.600 --> 00:08:07.860 had variables that were often global, meaning 00:08:07.860 --> 00:08:10.279 any function anywhere in the system could potentially 00:08:10.279 --> 00:08:13.139 modify any piece of data at any time. That's 00:08:13.139 --> 00:08:15.160 precisely the problem. The core philosophical 00:08:15.160 --> 00:08:18.199 struggle Liskov tackled was managing that sheer 00:08:18.199 --> 00:08:21.139 volume of implicit dependencies. As programs 00:08:21.139 --> 00:08:24.000 got bigger, it became impossible for one programmer 00:08:24.000 --> 00:08:27.040 or even a large team to hold all the implementation 00:08:27.040 --> 00:08:29.980 details in their head. So if one developer changed 00:08:29.980 --> 00:08:32.419 how they stored a list. Right, say from array 00:08:32.419 --> 00:08:35.039 to a linked list. Then another developer's function, 00:08:35.320 --> 00:08:37.559 one that relied on the old storage method, would 00:08:37.559 --> 00:08:40.740 just break. catastrophically. The reliance on 00:08:40.740 --> 00:08:43.779 hidden internal implementation details meant 00:08:43.779 --> 00:08:46.580 the systems were incredibly brittle. It's like 00:08:46.580 --> 00:08:49.019 trying to fix a skyscraper by relying on your 00:08:49.019 --> 00:08:51.360 internal knowledge of which individual steel 00:08:51.360 --> 00:08:54.320 rivet was used in every single wall. You couldn't 00:08:54.320 --> 00:08:57.159 swap out or upgrade components without tearing 00:08:57.159 --> 00:08:59.559 down the entire structure. And that need for 00:08:59.559 --> 00:09:02.820 isolation, for compartmentalization, is what 00:09:02.820 --> 00:09:06.299 led directly to her pioneering work on abstract 00:09:06.700 --> 00:09:09.460 data types or ADTs and the principle of data 00:09:09.460 --> 00:09:12.320 abstraction. Her landmark paper, Programming 00:09:12.320 --> 00:09:15.519 with Abstract Data Types from 1974. Foundational 00:09:15.519 --> 00:09:18.240 stuff. Truly foundational. OK, we need to nail 00:09:18.240 --> 00:09:20.320 this down for the listener. What is the concept 00:09:20.320 --> 00:09:22.480 of abstract data types and how did it impose 00:09:22.480 --> 00:09:25.460 order on that chaos? Data abstraction is the 00:09:25.460 --> 00:09:27.519 idea that a data structure should be defined 00:09:27.519 --> 00:09:30.120 entirely by the set of operations you can perform 00:09:30.120 --> 00:09:32.639 on it. Forget about how the data is stored. That's 00:09:32.639 --> 00:09:34.679 an implementation detail. So you're only focused 00:09:34.679 --> 00:09:37.720 on the functional contract. Exactly. What actions 00:09:37.720 --> 00:09:41.059 can I perform and what results do I expect? That's 00:09:41.059 --> 00:09:42.740 all that should matter to the outside world. 00:09:43.019 --> 00:09:45.980 So if I create a stack data type, you know, a 00:09:45.980 --> 00:09:48.259 standard structure where the last item in is 00:09:48.259 --> 00:09:50.820 the first item out. LIFO, yeah. I define it only 00:09:50.820 --> 00:09:54.399 by its operations. Push to add an item and pop 00:09:54.399 --> 00:09:57.220 to remove one. I don't define it by whether the 00:09:57.220 --> 00:09:59.940 computer stores those items in a contiguous array 00:09:59.940 --> 00:10:03.580 or a scattered linked list. Precisely. Liskov's 00:10:03.580 --> 00:10:07.090 work emphasized encapsulation. hiding the implementation 00:10:07.090 --> 00:10:10.389 details inside a secure boundary. This makes 00:10:10.389 --> 00:10:13.370 the code modular, easier to manage, and dramatically 00:10:13.370 --> 00:10:15.970 more reliable. Which means if you, the developer, 00:10:16.110 --> 00:10:18.649 decide to optimize that stack later, maybe you 00:10:18.649 --> 00:10:21.009 change it from a slow linked list to a faster 00:10:21.009 --> 00:10:23.409 optimized array. The rest of the program that 00:10:23.409 --> 00:10:25.169 uses your stack doesn't need to change at all. 00:10:25.210 --> 00:10:27.289 Not one line of code. Because the abstraction 00:10:27.289 --> 00:10:29.330 shields the rest of the system from the change. 00:10:29.470 --> 00:10:31.750 That's the core insight that enables continuous 00:10:31.750 --> 00:10:34.129 improvement and rapid iteration today. Absolutely. 00:10:34.389 --> 00:10:36.850 You can swap out an entire microservice without 00:10:36.850 --> 00:10:38.809 telling the front end, as long as that service 00:10:38.809 --> 00:10:41.519 maintains its external contract, its API. It's 00:10:41.519 --> 00:10:43.340 the same principle. It's the exact same principle. 00:10:43.500 --> 00:10:46.120 And Liskov didn't stop at theory. She created 00:10:46.120 --> 00:10:48.980 a language to enforce these principles rigorously. 00:10:49.159 --> 00:10:52.500 This was the CLU project developed in the 1970s. 00:10:52.519 --> 00:10:55.559 So CLU was designed explicitly to embody these 00:10:55.559 --> 00:10:59.019 ADTs. What was the specific language mechanism 00:10:59.019 --> 00:11:03.340 within CLU that enforced this abstraction? CLU 00:11:03.340 --> 00:11:06.360 introduced the concept of the cluster. A cluster 00:11:06.360 --> 00:11:08.620 was the fundamental structure for defining an 00:11:08.620 --> 00:11:11.289 abstract data type. It grouped together the data 00:11:11.289 --> 00:11:13.450 structure itself and the set of procedures or 00:11:13.450 --> 00:11:16.570 operations that acted upon that data. And crucially, 00:11:16.649 --> 00:11:19.309 CLU strictly enforced that the data within the 00:11:19.309 --> 00:11:21.409 cluster could only be manipulated by the procedures 00:11:21.409 --> 00:11:24.610 inside that same cluster. That sounds like the 00:11:24.610 --> 00:11:26.750 direct and sexual ancestor of the modern class 00:11:26.750 --> 00:11:29.070 structure, where you have private internal fields 00:11:29.070 --> 00:11:31.450 and public methods. It is the direct ancestor. 00:11:31.669 --> 00:11:34.110 The cluster concept, this idea of a data type 00:11:34.110 --> 00:11:36.350 that owns its state and exposes only a defined 00:11:36.350 --> 00:11:39.669 set of operations, was revolutionary. It provided 00:11:39.669 --> 00:11:42.269 a powerful discipline tool for structuring large 00:11:42.269 --> 00:11:45.090 software systems. And this brings us to the key 00:11:45.090 --> 00:11:47.909 aha moment for anyone interested in programming 00:11:47.909 --> 00:11:51.669 history. While CLU itself might not be used today. 00:11:52.090 --> 00:11:54.669 No, it's not. Its DNA is everywhere. That is 00:11:54.669 --> 00:11:58.009 the core legacy impact. The mechanisms CLU introduced 00:11:58.009 --> 00:12:00.370 for data abstraction clusters, its methods for 00:12:00.370 --> 00:12:03.009 exception handling, iterators, were enormously 00:12:03.009 --> 00:12:06.710 influential on the design of several later massively 00:12:06.710 --> 00:12:08.809 popular programming languages. And the source 00:12:08.809 --> 00:12:10.950 material specifically calls out some big ones. 00:12:11.110 --> 00:12:13.929 The biggest. It references Java, C++ and Data, 00:12:14.049 --> 00:12:17.340 C Sharp, and Ada. When you use classes, when 00:12:17.340 --> 00:12:19.720 you define interfaces, when you enforce data 00:12:19.720 --> 00:12:22.259 hiding using private or protected keywords in 00:12:22.259 --> 00:12:24.659 any of these modern languages, you are applying 00:12:24.659 --> 00:12:27.279 concepts traced directly back to Barbara Liskov's 00:12:27.279 --> 00:12:30.370 work on CLU. So to sum up this part, she basically 00:12:30.370 --> 00:12:32.769 defined how modern languages organize data for 00:12:32.769 --> 00:12:35.470 reliability and reuse. She provided the blueprints 00:12:35.470 --> 00:12:37.710 for building modular software components that 00:12:37.710 --> 00:12:39.850 don't leak their fragile internal details. Well 00:12:39.850 --> 00:12:42.450 said. So data abstraction fixed the component 00:12:42.450 --> 00:12:45.870 level, how we define a single robust data type. 00:12:46.440 --> 00:12:49.940 But the field kept evolving, right? And soon, 00:12:50.120 --> 00:12:53.179 object -oriented programming, OOP, introduced 00:12:53.179 --> 00:12:55.879 these complex relationships between types. That's 00:12:55.879 --> 00:12:58.120 right. So the next challenge was figuring out 00:12:58.120 --> 00:13:01.379 how to manage inheritance and subtyping as programs 00:13:01.379 --> 00:13:03.919 grew. Abstraction fixed the internal structural 00:13:03.919 --> 00:13:06.659 integrity of a component. But OOP introduced 00:13:06.659 --> 00:13:08.639 a new mechanism that threatened to undermine 00:13:08.639 --> 00:13:12.019 that integrity. Inheritance. You had a base type, 00:13:12.159 --> 00:13:15.269 let's call it T, and then you subtype. S that 00:13:15.269 --> 00:13:17.230 inherits from it. Okay. And programmers wanted 00:13:17.230 --> 00:13:19.169 to be able to substitute an object of type S 00:13:19.169 --> 00:13:21.769 anywhere an object of type T was expected. So 00:13:21.769 --> 00:13:24.169 if I have a base class called animal and I create 00:13:24.169 --> 00:13:26.610 a subclass called dog, I should be able to pass 00:13:26.610 --> 00:13:29.370 a dog to any function that expect an animal without 00:13:29.370 --> 00:13:32.049 worrying about crashing the system. Exactly. 00:13:32.230 --> 00:13:34.409 The problem was traditional type checking only 00:13:34.409 --> 00:13:36.539 looked at the structure. Do the methods have 00:13:36.539 --> 00:13:38.259 the same names and the same number of arguments? 00:13:38.460 --> 00:13:40.259 But what you really need is a rule that ensures 00:13:40.259 --> 00:13:42.559 behavioral compatibility. What do you mean by 00:13:42.559 --> 00:13:44.820 behavioral compatibility? Well, if the dog suddenly 00:13:44.820 --> 00:13:47.259 violates an implicit guarantee made by animal, 00:13:47.440 --> 00:13:51.120 say, the animal .eat method always consumes food, 00:13:51.220 --> 00:13:53.740 but the dog .eat method sometimes just throws 00:13:53.740 --> 00:13:56.720 the food away, then substituting the dog breaks 00:13:56.720 --> 00:13:59.340 the system's expected behavior. Even if the method 00:13:59.340 --> 00:14:01.879 name is the same? Even if the structure is identical. 00:14:02.480 --> 00:14:05.620 The behavior is wrong, and this need for a formal 00:14:05.620 --> 00:14:08.580 mathematical rule to govern how these subtypes 00:14:08.580 --> 00:14:11.039 should relate to their base types to ensure the 00:14:11.039 --> 00:14:14.080 overall code remains robust led to the development 00:14:14.080 --> 00:14:16.860 of what is known universally today as the Liskov 00:14:16.860 --> 00:14:19.820 Substitution Principle, or LSP. She developed 00:14:19.820 --> 00:14:22.279 this principle with Jeanette Wing. She did, and 00:14:22.279 --> 00:14:24.559 it was formally referenced in their 1994 paper, 00:14:24.740 --> 00:14:27.659 A Behavioral Notion of Subtyping, and that phrasing 00:14:27.659 --> 00:14:30.080 is key. It is specifically a behavioral notion 00:14:30.080 --> 00:14:32.500 of subtyping. It focuses not on structural similarity, 00:14:32.799 --> 00:14:35.620 but on how the subtype acts in the system. Okay, 00:14:35.700 --> 00:14:37.779 so let's tackle the dense definition first, and 00:14:37.779 --> 00:14:39.700 then we'll immediately make it accessible. What's 00:14:39.700 --> 00:14:42.100 the formal statement of the LSP? The LSP states, 00:14:42.299 --> 00:14:45.620 if S is a subtype of T, then objects of type 00:14:45.620 --> 00:14:48.519 T may be replaced with objects of type S without 00:14:48.519 --> 00:14:50.679 offering any of the desirable properties of the 00:14:50.679 --> 00:14:53.539 program. Okay, that is classic computer science 00:14:53.539 --> 00:14:56.980 formality. It's concise, but a bit abstract. 00:14:57.980 --> 00:15:00.500 The implication, though, is incredibly powerful. 00:15:01.100 --> 00:15:03.679 And I think the best way to clarify why structural 00:15:03.679 --> 00:15:06.379 inheritance isn't enough is with that classic 00:15:06.379 --> 00:15:09.419 analogy, the square and the rectangle. The perfect 00:15:09.419 --> 00:15:12.240 example. Structurally, a square is a type of 00:15:12.240 --> 00:15:14.679 rectangle. A rectangle has a width and a height, 00:15:14.799 --> 00:15:17.080 and you have procedures to set those independently. 00:15:17.460 --> 00:15:20.179 Right. A square has a side length, but mathematically 00:15:20.179 --> 00:15:22.399 you could say it's a rectangle where width equals 00:15:22.399 --> 00:15:24.879 height. So if we follow the basic structural 00:15:24.879 --> 00:15:27.460 inheritance rule, it seems logical to make the 00:15:27.460 --> 00:15:29.440 square class inherit from the rectangle class. 00:15:29.720 --> 00:15:32.080 It does seem logical. But here's the behavioral 00:15:32.080 --> 00:15:34.600 conflict. The rectangle class guarantees that 00:15:34.600 --> 00:15:36.899 you can set the width to 10 and the height to 00:15:36.899 --> 00:15:39.419 5. That's part of its contract. Okay. Now, if 00:15:39.419 --> 00:15:41.399 I substitute a square object where a rectangle 00:15:41.399 --> 00:15:43.940 object is expected and the program calls set 00:15:43.940 --> 00:15:46.539 width and then set height 5, the square object 00:15:46.539 --> 00:15:49.039 must break that expectation to maintain its own 00:15:49.039 --> 00:15:51.440 invariant, which is that width must equal height. 00:15:51.659 --> 00:15:54.279 So it might force the height to 10 as well or 00:15:54.279 --> 00:15:56.480 maybe throw an error. Right. It does something 00:15:56.480 --> 00:15:59.620 unexpected. The square subtype violates the behavioral 00:15:59.620 --> 00:16:03.120 contract of the rectangle base type, which implicitly 00:16:03.120 --> 00:16:05.360 promises that set width does not affect height. 00:16:05.879 --> 00:16:08.620 Any code expecting a rectangle will now get an 00:16:08.620 --> 00:16:10.899 unexpected outcome when dealing with a square. 00:16:11.100 --> 00:16:13.620 And that's a violation of LSP. That's where bugs 00:16:13.620 --> 00:16:16.279 come from. Exactly. The square rectangle problem 00:16:16.279 --> 00:16:19.059 shows that subtyping must be based on observable 00:16:19.059 --> 00:16:21.860 behavior and contracts, not just structural convenience. 00:16:22.860 --> 00:16:25.500 The LSP ensures that the subtype upholds all 00:16:25.500 --> 00:16:28.940 the implicit and explicit guarantees, the preconditions 00:16:28.940 --> 00:16:32.019 and postconditions of the base type. Here's where 00:16:32.019 --> 00:16:34.039 it gets really interesting for software architects. 00:16:34.519 --> 00:16:37.860 This principle ensures true reliability and reusability. 00:16:38.399 --> 00:16:41.039 Because if a code base strictly adheres to LSP, 00:16:41.299 --> 00:16:43.399 I can write general code that works with the 00:16:43.399 --> 00:16:45.679 base type, and I know that any new specialized 00:16:45.679 --> 00:16:47.799 subtype that someone adds five years from now 00:16:47.799 --> 00:16:50.000 will work perfectly with my old code. It creates 00:16:50.000 --> 00:16:52.159 a system that's robust against future specialization. 00:16:52.570 --> 00:16:54.889 It forces programmers to think about the contracts 00:16:54.889 --> 00:16:57.250 their code makes, rather than just the structure. 00:16:57.600 --> 00:16:59.480 It seems like it connects directly to modern 00:16:59.480 --> 00:17:02.539 concepts like interface segregation and solid 00:17:02.539 --> 00:17:05.660 design principles. It's the L in solid. It promotes 00:17:05.660 --> 00:17:09.079 decoupled, maintainable code bases. Without LSP, 00:17:09.380 --> 00:17:12.019 object -oriented programming would be a fragile 00:17:12.019 --> 00:17:14.640 mess of unpredictable substitutions. And the 00:17:14.640 --> 00:17:16.819 power of this principle is still recognized today, 00:17:16.920 --> 00:17:20.500 nearly 30 years after that paper. The 2023 citation 00:17:20.500 --> 00:17:22.680 she received for the Benjamin Franklin Medal 00:17:22.680 --> 00:17:26.440 specifically recognized her work for... What 00:17:26.440 --> 00:17:33.220 was it? That citation is a testament to the fact 00:17:33.220 --> 00:17:35.480 that her work didn't just solve an academic problem. 00:17:35.680 --> 00:17:39.000 It gave the software industry the necessary guardrails 00:17:39.000 --> 00:17:41.799 to scale complexity. It's the invisible structural 00:17:41.799 --> 00:17:43.960 integrity that makes large systems manageable, 00:17:44.220 --> 00:17:46.660 testable, and reliable. That's a fascinating 00:17:46.660 --> 00:17:49.119 evolution, from fixing data encapsulation on 00:17:49.119 --> 00:17:51.519 a single machine with CLU to defining structural 00:17:51.519 --> 00:17:54.200 rules for inheritance with LSP. But her career 00:17:54.200 --> 00:17:56.420 didn't stop at the boundaries of a single program. 00:17:56.599 --> 00:17:58.720 Not at all. Her focus naturally evolved to the 00:17:58.720 --> 00:18:01.079 ultimate complexity, handling multiple machines 00:18:01.079 --> 00:18:03.319 working together, often across vast distances. 00:18:03.720 --> 00:18:06.819 Her career trajectory shows this consistent march 00:18:06.819 --> 00:18:09.420 towards solving the biggest problems in system 00:18:09.420 --> 00:18:12.069 integrity. She started with making programs reliable, 00:18:12.309 --> 00:18:15.369 and then she moved to making entire systems composed 00:18:15.369 --> 00:18:18.549 of multiple, often distant, machines reliable, 00:18:18.809 --> 00:18:21.230 even in the face of failure. This is the domain 00:18:21.230 --> 00:18:23.390 of distributed computing and fault tolerance. 00:18:23.710 --> 00:18:26.470 Right. And we see evidence of her early leadership 00:18:26.470 --> 00:18:29.470 in system design right after she joined MIT, 00:18:29.589 --> 00:18:32.019 where she led Project Venus. What is Project 00:18:32.019 --> 00:18:34.519 Venus? The Venus operating system was an important 00:18:34.519 --> 00:18:36.960 early leadership role for her. It was developed 00:18:36.960 --> 00:18:40.160 as a small, low -cost time -sharing system focusing 00:18:40.160 --> 00:18:43.019 on efficient resource management, a very practical 00:18:43.019 --> 00:18:45.660 system architecture challenge. But the next stage, 00:18:45.980 --> 00:18:48.700 Argus, was her seminal contribution to distributed 00:18:48.700 --> 00:18:51.420 programming. Detail Argus for us. When was it 00:18:51.420 --> 00:18:53.980 developed and what was its core innovation? Argus 00:18:53.980 --> 00:18:56.579 was developed in the 1980s. Its historical significance 00:18:56.579 --> 00:18:59.470 is massive. It was the first high -level language 00:18:59.470 --> 00:19:01.710 specifically designed to support the implementation 00:19:01.710 --> 00:19:04.250 of distributed programs. It introduced these 00:19:04.250 --> 00:19:07.390 concepts of guardians and atomic actions. Guardians 00:19:07.390 --> 00:19:09.789 and atomic actions. That sounds like she was 00:19:09.789 --> 00:19:12.250 trying to package up that CLU abstraction idea 00:19:12.250 --> 00:19:14.869 and scale it across a network. That's a great 00:19:14.869 --> 00:19:17.250 way to put it. A guardian was essentially a container 00:19:17.250 --> 00:19:20.029 for data and processes that could persist and 00:19:20.029 --> 00:19:22.789 be located across the network. And atomic actions 00:19:22.789 --> 00:19:24.990 were Argus's mechanism for managing distributed 00:19:24.990 --> 00:19:27.470 transactions. Which ensures that operations across 00:19:27.470 --> 00:19:30.109 multiple machines are all or nothing. All or 00:19:30.109 --> 00:19:31.930 nothing. Either every machine commits the change 00:19:31.930 --> 00:19:35.190 successfully, or if any one machine fails, they 00:19:35.190 --> 00:19:37.569 all revert back to the previous stable state. 00:19:37.710 --> 00:19:40.549 This is the foundation of reliable networked 00:19:40.549 --> 00:19:42.849 operations, like booking a flight and paying 00:19:42.849 --> 00:19:45.210 for it. And Argus also demonstrated a specific 00:19:45.210 --> 00:19:47.890 technical achievement that is crucial for performance 00:19:47.890 --> 00:19:50.549 optimization in high -latency network environments. 00:19:51.450 --> 00:19:54.309 Promise pipelining. That sounds complex, but 00:19:54.309 --> 00:19:57.170 essential for speed. It is. Promise pipelining 00:19:57.170 --> 00:20:00.029 is a technique to hide latency. When a request 00:20:00.029 --> 00:20:02.089 is sent across a network, say from machine A 00:20:02.089 --> 00:20:04.289 to machine B, instead of just sitting there and 00:20:04.289 --> 00:20:06.490 waiting for B to respond before sending the next 00:20:06.490 --> 00:20:08.829 related request. Which is a huge waste of time. 00:20:09.309 --> 00:20:12.289 Erkin sent several requests sequentially. Assuming 00:20:12.289 --> 00:20:14.890 the prior ones will succeed. It's setting a promise 00:20:14.890 --> 00:20:17.170 of the next step. So instead of request one, 00:20:17.289 --> 00:20:20.730 wait, request two, wait. You send request one, 00:20:20.789 --> 00:20:22.990 then immediately send request two, and then you 00:20:22.990 --> 00:20:25.670 can wait for both replies in sequence. Yes. You 00:20:25.670 --> 00:20:28.069 essentially pipeline the communication, significantly 00:20:28.069 --> 00:20:31.309 reducing the perceived latency in a system where 00:20:31.309 --> 00:20:34.329 communication delays are the primary bottleneck. 00:20:34.829 --> 00:20:36.930 Argus really laid the groundwork for managing 00:20:36.930 --> 00:20:39.029 distributed transactions and communication efficiently. 00:20:39.630 --> 00:20:42.309 This expansion into distributed systems eventually 00:20:42.309 --> 00:20:45.009 led to her most critical contribution to system 00:20:45.009 --> 00:20:47.549 architecture in the modern era. And it's one 00:20:47.549 --> 00:20:49.450 that is absolutely essential for things like 00:20:49.450 --> 00:20:51.890 blockchain, financial ledgers and secure cloud 00:20:51.890 --> 00:20:53.769 infrastructure. You're talking about her research 00:20:53.769 --> 00:20:56.750 focus on Byzantine fault tolerance. Yes. To put 00:20:56.750 --> 00:20:59.630 this in context, reliability in the 1970s meant 00:20:59.630 --> 00:21:02.589 protecting against simple software bugs. Abstraction 00:21:02.589 --> 00:21:05.230 solved that. Reliability in the 80s meant protecting 00:21:05.230 --> 00:21:07.829 against simple crashes. Distributed transactions 00:21:07.829 --> 00:21:11.049 solved that. And reliability in the 90s. Reliability 00:21:11.049 --> 00:21:13.569 in the 1990s meant protecting against malicious, 00:21:13.789 --> 00:21:16.990 unpredictable failures. That is the crucial distinction. 00:21:17.640 --> 00:21:20.420 We've moved beyond fail -stop failures, where 00:21:20.420 --> 00:21:22.599 a component just stops working and is easily 00:21:22.599 --> 00:21:25.880 detected, to arbitrary or Byzantine failures. 00:21:26.240 --> 00:21:29.660 An arbitrary or Byzantine failure means a component 00:21:29.660 --> 00:21:32.140 might send one piece of information to one part 00:21:32.140 --> 00:21:34.980 of the system and a contradictory false piece 00:21:34.980 --> 00:21:37.660 of information to another part. It's actively 00:21:37.660 --> 00:21:40.440 lying or acting erratically. The core challenge 00:21:40.440 --> 00:21:43.490 becomes... How do the remaining honest components 00:21:43.490 --> 00:21:46.430 reach a consensus when they can't trust the messages 00:21:46.430 --> 00:21:48.230 they're receiving? That's the challenge, is the 00:21:48.230 --> 00:21:51.130 famous Byzantine generals' problem. Commanders 00:21:51.130 --> 00:21:53.170 trying to agree on whether to attack or retreat, 00:21:53.410 --> 00:21:55.589 even though some messengers, or even some of 00:21:55.589 --> 00:21:57.670 the commanders themselves, might be traitors 00:21:57.670 --> 00:21:59.930 actively trying to sow confusion. And this is 00:21:59.930 --> 00:22:02.170 where Liskov, working with Miguel Castro, made 00:22:02.170 --> 00:22:05.109 a pivotal practical breakthrough in the 1990s. 00:22:05.130 --> 00:22:08.970 Their 1999 paper, Practical Byzantine Fault Tolerance, 00:22:08.990 --> 00:22:12.130 or PBFT. That paper demonstrated how a system 00:22:12.130 --> 00:22:14.130 could tolerate these kinds of failures efficiently. 00:22:14.650 --> 00:22:17.069 What was the key insight that made their solution 00:22:17.069 --> 00:22:20.150 practical? Because previous BFT solutions were 00:22:20.150 --> 00:22:23.109 often just too computationally expensive to use 00:22:23.109 --> 00:22:27.269 in real world systems. The PBFT approach focused 00:22:27.269 --> 00:22:29.170 on optimizing the communication requirements. 00:22:29.930 --> 00:22:32.549 Previous solutions required every node to communicate 00:22:32.549 --> 00:22:34.910 with every other node, which leads to this massive 00:22:34.910 --> 00:22:37.650 exponential overhead. Right. PBFT significantly 00:22:37.650 --> 00:22:40.190 reduced the number of messages needed to achieve 00:22:40.190 --> 00:22:43.279 consensus and commit an operation. provided a 00:22:43.279 --> 00:22:45.660 certain majority of the nodes were honest. Which 00:22:45.660 --> 00:22:48.039 means they created an algorithm that allowed 00:22:48.039 --> 00:22:51.119 an honest functioning system to isolate the malicious 00:22:51.119 --> 00:22:53.960 nodes and continue operating confirming the state 00:22:53.960 --> 00:22:56.319 of the system quickly and securely. Absolutely. 00:22:56.829 --> 00:22:59.869 This work is vital for trust. If you rely on 00:22:59.869 --> 00:23:02.470 a shared ledger or a large cloud system, you 00:23:02.470 --> 00:23:04.509 need guarantees that a single compromised component 00:23:04.509 --> 00:23:06.710 can't arbitrarily corrupt the entire database 00:23:06.710 --> 00:23:09.869 or provide contradictory results. And PBFT provided 00:23:09.869 --> 00:23:12.450 a fundamental, proven mechanism for creating 00:23:12.450 --> 00:23:14.670 digital trust in untrustworthy environments. 00:23:15.130 --> 00:23:17.230 And that area distributed computing and fault 00:23:17.230 --> 00:23:19.789 tolerance remains her current research focus 00:23:19.789 --> 00:23:22.720 at MIT. That is a staggering arc of research. 00:23:22.980 --> 00:23:25.619 From making an efficient chess algorithm in 1968 00:23:25.619 --> 00:23:28.960 to defining the structure of classes in the 70s 00:23:28.960 --> 00:23:31.299 to establishing the rules for inheritance in 00:23:31.299 --> 00:23:34.079 the 90s and then solving the consensus problem 00:23:34.079 --> 00:23:36.539 for global systems at the turn of the millennium. 00:23:36.599 --> 00:23:39.480 It's a career consistently focused on translating 00:23:39.480 --> 00:23:42.039 theoretical rigor into practical robustness. 00:23:42.279 --> 00:23:44.700 Solving these deep structural problems naturally 00:23:44.700 --> 00:23:47.839 led to, well, significant recognition across 00:23:47.839 --> 00:23:50.400 the field. When you look at her list of honors, 00:23:50.680 --> 00:23:53.619 it immediately establishes her status as a true 00:23:53.619 --> 00:23:56.920 pioneer whose work touches every corner of computer 00:23:56.920 --> 00:23:59.599 science. Her career culminates in this extraordinary 00:23:59.599 --> 00:24:02.059 collection of awards, demonstrating recognition 00:24:02.059 --> 00:24:05.220 across programming languages, methodology, systems 00:24:05.220 --> 00:24:08.099 design, you name it. And as we noted early on, 00:24:08.160 --> 00:24:10.259 we have to pause to reiterate the significance 00:24:10.259 --> 00:24:12.579 of the historical barriers she broke. She is 00:24:12.579 --> 00:24:15.079 the second woman ever to receive the A .M. Turing 00:24:15.079 --> 00:24:17.680 Award, often called the Nobel Prize of Computing. 00:24:18.349 --> 00:24:20.089 Considering the hurdles we talked about in her 00:24:20.089 --> 00:24:23.329 early career, that achievement is just all the 00:24:23.329 --> 00:24:25.869 more profound. Let's maybe detail the major awards, 00:24:26.109 --> 00:24:28.930 because the citations themselves really summarize 00:24:28.930 --> 00:24:31.730 the immense scope of her influence. We can start 00:24:31.730 --> 00:24:33.930 with the I .E. John von Neumann Medal, which 00:24:33.930 --> 00:24:37.710 came first. That was in 2004. 2004. And the citation 00:24:37.710 --> 00:24:40.950 specifically recognized her for fundamental contributions 00:24:40.950 --> 00:24:43.390 to programming languages, programming methodology, 00:24:43.710 --> 00:24:45.869 and distributed systems. That's the perfect summary. 00:24:45.950 --> 00:24:49.490 It hits her work on CLU, LSP, and Argus BFT all 00:24:49.490 --> 00:24:51.769 at once. It does. Then, of course, the big one, 00:24:51.910 --> 00:24:55.309 the A .M. Turing Award for 2008. She received 00:24:55.309 --> 00:24:57.349 it from the Association for Computing Machinery, 00:24:57.430 --> 00:25:00.069 presented in March of 2009. And the award was 00:25:00.069 --> 00:25:02.369 explicitly given for her fundamental work on 00:25:02.369 --> 00:25:05.910 programming language and system design. The ACM 00:25:05.910 --> 00:25:07.930 cited her contributions to the practical and 00:25:07.930 --> 00:25:10.410 theoretical foundations of programming language 00:25:10.410 --> 00:25:13.609 and system design, especially related to data 00:25:13.609 --> 00:25:15.849 abstraction, fault tolerance and distributed 00:25:15.849 --> 00:25:18.390 computing. It's just so rare to see a career 00:25:18.390 --> 00:25:21.289 that bridges the theoretical language design 00:25:21.289 --> 00:25:23.309 work. You know how a single programmer writes 00:25:23.309 --> 00:25:26.490 code with the massive practical systemic challenges 00:25:26.490 --> 00:25:29.190 of distributed fault tolerance. The Turing Award 00:25:29.190 --> 00:25:32.390 recognizes the totality of that. And the awards 00:25:32.390 --> 00:25:35.450 just kept coming into the next. decade. In 2012, 00:25:35.670 --> 00:25:38.130 she was inducted into the National Inventors 00:25:38.130 --> 00:25:40.630 Hall of Fame. Recognizing the invention of her 00:25:40.630 --> 00:25:43.250 principles and languages. Exactly. And as we 00:25:43.250 --> 00:25:45.730 mentioned in the context of the LSP, she received 00:25:45.730 --> 00:25:48.869 the Benjamin Franklin Medal in 2023 for enabling 00:25:48.869 --> 00:25:51.630 the implementation of reliable, reusable programs. 00:25:51.910 --> 00:25:54.789 And beyond these major technical awards, she's 00:25:54.789 --> 00:25:56.950 been recognized broadly by the academic community, 00:25:57.250 --> 00:26:00.069 receiving multiple honorary doctorates. From 00:26:00.069 --> 00:26:03.410 ETH Zurich. the University of Lugano, the Universidad 00:26:03.410 --> 00:26:05.690 Politécnica de Madrid. She's a fellow of all 00:26:05.690 --> 00:26:08.869 the major academic bodies, the ACM, the American 00:26:08.869 --> 00:26:11.569 Academy of Arts and Sciences, and a member of 00:26:11.569 --> 00:26:13.549 both the National Academy of Engineering and 00:26:13.549 --> 00:26:15.930 the National Academy of Sciences. And to emphasize 00:26:15.930 --> 00:26:18.430 her standing within MIT, she holds the title 00:26:18.430 --> 00:26:21.269 of Institute Professor, which is reserved for 00:26:21.269 --> 00:26:23.289 a very, very small number of distinguished faculty. 00:26:23.750 --> 00:26:26.710 She was also recognized back in 2002 as one of 00:26:26.710 --> 00:26:29.069 the 50 most important women in science by Discover 00:26:29.069 --> 00:26:31.619 Magazine. It's so clear that the impact she had 00:26:31.619 --> 00:26:33.960 on the design of software structure is generational. 00:26:34.779 --> 00:26:37.319 And before we wrap up, it's also nice to briefly 00:26:37.319 --> 00:26:39.680 note a personal legacy that has followed in her 00:26:39.680 --> 00:26:42.259 footsteps. It is. Barbara Liskoff married Nathan 00:26:42.259 --> 00:26:45.819 Liskoff in 1970. They have one son, Moses, who 00:26:45.819 --> 00:26:48.279 also pursued computer science. He also earned 00:26:48.279 --> 00:26:51.720 a Ph .D. from MIT, right? In 2004. He did. And 00:26:51.720 --> 00:26:53.359 now he teaches the subject at the College of 00:26:53.359 --> 00:26:55.819 William and Mary. It's a multi -generational 00:26:55.819 --> 00:26:58.240 commitment to advancing the core tenets of the 00:26:58.240 --> 00:27:01.119 field. So to synthesize this immense impact, 00:27:01.460 --> 00:27:04.460 her entire career demonstrates this consistent, 00:27:04.559 --> 00:27:07.480 decades -long focus on elevating software engineering 00:27:07.480 --> 00:27:10.740 from, I guess, a highly customized, fragile craft 00:27:10.740 --> 00:27:13.720 into a disciplined, scalable engineering practice. 00:27:14.059 --> 00:27:16.160 She invented the rules that govern good software 00:27:16.160 --> 00:27:18.619 structure. She ensured systems could grow without 00:27:18.619 --> 00:27:21.299 collapsing. Her theoretical concepts, the requirement 00:27:21.299 --> 00:27:23.859 of abstraction through ADTs, the necessity of 00:27:23.859 --> 00:27:26.599 behavioral subtyping through LSP, and the ability 00:27:26.599 --> 00:27:28.579 to maintain consensus through BFT, they're not 00:27:28.579 --> 00:27:31.440 just academic footnotes. No, not at all. They 00:27:31.440 --> 00:27:33.920 are the core intellectual property underpinning 00:27:33.920 --> 00:27:36.460 the robustness of critical modern digital infrastructure. 00:27:37.500 --> 00:27:40.400 Without her insights, complex code bases would 00:27:40.400 --> 00:27:42.700 collapse under their own weight the first time 00:27:42.700 --> 00:27:45.200 an engineer needed to swap a component or update 00:27:45.200 --> 00:27:47.880 a data structure. Stepping back. Her work really 00:27:47.880 --> 00:27:50.420 defined the rules of structural integrity for 00:27:50.420 --> 00:27:52.940 object -oriented systems and distributed networks. 00:27:53.279 --> 00:27:55.839 It did. She ensured that when you try to build 00:27:55.839 --> 00:27:58.359 something bigger than a simple script, the theoretical 00:27:58.359 --> 00:28:01.299 foundations are sound enough to prevent catastrophic 00:28:01.299 --> 00:28:04.660 failure, even when parts are being swapped out, 00:28:04.740 --> 00:28:07.700 or, critically, when those parts might be acting 00:28:07.700 --> 00:28:10.650 maliciously. It's a powerful reminder that the 00:28:10.650 --> 00:28:12.950 complexity of the digital world is managed not 00:28:12.950 --> 00:28:15.369 through brute force computing, but through elegant 00:28:15.369 --> 00:28:18.549 fundamental principles. And Liskov provided the 00:28:18.549 --> 00:28:21.470 conceptual clarity needed to handle massive collaborative 00:28:21.470 --> 00:28:24.910 software projects reliably. So we end with this 00:28:24.910 --> 00:28:27.670 provocative thought for you, the listener. Remember 00:28:27.670 --> 00:28:30.630 that Barbara Liskov's doctoral thesis, the work 00:28:30.630 --> 00:28:32.869 that launched her career in computing, involved 00:28:32.869 --> 00:28:36.029 designing a program to solve complex niche problems 00:28:36.029 --> 00:28:40.029 and chess end games. introduced the killer heuristic. 00:28:40.130 --> 00:28:42.829 Highly specific and academic. Very. Yet that 00:28:42.829 --> 00:28:45.369 kind of fundamental theoretical work, whether 00:28:45.369 --> 00:28:47.930 it's optimizing search in a game, defining theoretical 00:28:47.930 --> 00:28:50.589 abstraction, or solving the Byzantine generals 00:28:50.589 --> 00:28:53.650 problem, so often becomes the invisible critical 00:28:53.650 --> 00:28:56.369 foundation for trillion dollar industries. That's 00:28:56.369 --> 00:28:58.490 a great point. Her early work laid the groundwork 00:28:58.490 --> 00:29:01.890 for robust class structures in Java and C++A, 00:29:02.069 --> 00:29:04.650 and her later work underpins consensus mechanisms 00:29:04.650 --> 00:29:07.390 used in blockchain and high security cloud networks. 00:29:07.710 --> 00:29:11.069 So the question is, what other seemingly esoteric 00:29:13.809 --> 00:29:16.910 Maybe in quantum computing algorithms or new 00:29:16.910 --> 00:29:19.009 mathematical concepts for trustless systems.