316: Obviously Wasn't Obvious
Transcript from 316: Obviously Wasn't Obvious with Barbara Liskov, Chris White, and Elecia White.
EW (00:06):
Welcome to Embedded. I am Elecia White, here with Christopher White. And this week we are talking to Professor Barbara Liskov of MIT. You may have heard of her.
CW (00:18):
Hello, Professor Liskov. Welcome.
BL (00:21):
Thank you.
EW (00:22):
Could you tell us about yourself as though you were on a panel?
BL (00:27):
Well, as you said earlier, I'm a professor at MIT. I'm in the Electrical Engineering and Computer Science Department. I'm a computer scientist. I got into the field quite early, and this meant that I had the opportunity to work on some really interesting things that have led to the way that computing is today.
EW (00:51):
Yes, you've worked on many interesting things. Before I ask more about those, we want do lightning round, where we'll ask you short questions, and we want short answers. Are you ready?
BL (01:04):
Yeah.
EW (01:05):
Favorite college course to teach?
BL (01:09):
Well, I have been teaching computer science for many years, and I guess that a couple of the courses that I taught were my favorites. One of them was the course I developed myself with my colleague, John Guttag, which was a course in how to write big programs. Another one was a course on computer systems.
CW (01:33):
Do you have a Hopper nanosecond?
BL (01:35):
Do I have a what?
EW (01:36):
A Grace Hopper nanosecond?
BL (01:40):
No, I don't.
EW (01:42):
Okay.
BL (01:42):
I don't actually know what that is.
CW (01:45):
When somebody finds out what you do, what question do they tend to ask you?
BL (01:50):
I'm not sure that there's any particular question that comes to mind. It's very hard to explain what I do to people who are not computer scientists, because it has to do with how you organize programs and other kind of technical details that don't relate directly to applications. So it's a little difficult.
EW (02:13):
Do you have a favorite programming language or a least favorite programming language?
BL (02:18):
Well, I guess that my favorite programming language is the one that I developed myself in the 1970s.
EW (02:29):
CLU.
BL (02:30):
CLU. CLU. Yes. I'm not sure that I have a least favorite language.
CW (02:38):
I'm going to ask you a random question, and you may not know the answer. Was CLU the inspiration for the character in Tron?
BL (02:46):
It might have been, but I don't know the answer for sure.
CW (02:50):
Okay. Do you have a favorite theorem or algorithm?
BL (02:55):
I wouldn't say so.
CW (02:57):
Equal opportunity.
BL (02:58):
Equal opportunity. Right.
EW (03:01):
Yes. We should have asked a favorite abstraction.
BL (03:03):
A favorite abstraction. Right. Yeah.
EW (03:07):
So you're a professor at MIT. How long have you been there?
BL (03:11):
I have been at MIT since 1972.
EW (03:14):
You've been a professor at MIT since 1972.
BL (03:16):
That's right. Yep.
EW (03:19):
How have things changed in computer science since you were one of the first women to graduate with a PhD in computer science?
BL (03:29):
Well, when I got my PhD, computer science was still in its infancy and people didn't understand very well how to organize big programs. There weren't any distributed systems like what we're familiar with today, with the cloud and all the different computers connected by networks. They're just sort of getting started in trying to figure out how to do things. So it's changed tremendously.
EW (04:06):
How is it different to make a big system versus an iPhone app or some other application? What are the first few things you tell your students that they have to start thinking about?
BL (04:21):
Well, first of all, some apps might be big. ...
EW (04:27):
Yeah.
BL (04:27):
So computer programs are really big. There are millions of lines of code. They need to be worked on by many different people. They live for a long time. And so after the original development is done, additional people may get involved in maintaining them and adding new features.
BL (04:52):
So you have to have a way of organizing them that allows people to understand them and reason about them. When you're working on a small program, and it's just you, you can kind of throw it together. You're the only one involved.
BL (05:09):
But when you start to work on big systems, you have to break them up into components that we call modules and think about each module independently. And that is the core problem, how do you break systems up into modules? And what are these modules that impact software development?
EW (05:29):
I mean, I think about good APIs and as few cross-module variables as humanly possible, and trying to keep data in one area, but not anywhere else. I mean, these all have real formal names, but what else are you looking at when you're making modules? Is there advice that maybe people don't know?
BL (06:01):
Well, the things that you just mentioned are important things, and it's not easy when you're designing a large system to figure out what the module should be.
EW (06:16):
No, it isn't.
BL (06:17):
You also have to think about how the program might change in the future. Because you can design in such a way that it's easy to accommodate certain kinds of changes. So that's another thing you think about when you're designing a big system.
EW (06:39):
And you did your dissertation, when you got your PhD, on playing chess. How did you get from there to big systems?
BL (06:51):
So when I went to Stanford, I started working with John McCarthy, and John was a specialist in artificial intelligence. And so I did my thesis in AI. At the time I did that work, the idea with artificial intelligence was that you wanted your programs to work sort of the way people think about things.
BL (07:20):
And so my thesis was about picking up certain ideas about how to play chess endgames and getting them into the program so the program could work the way it was recommended that people think about these endgames.
BL (07:36):
I knew partway through my PhD that I actually wanted to switch out of AI and into computer systems. But I decided to wait until I finished my PhD, since I thought I would finish it faster that way. And as soon as I finished at Stanford, I switched out of AI and into computer systems.
CW (07:54):
What made you switch?
BL (07:56):
AI has changed a lot, and I felt that it had an awful long way to go before it was going to be able to tackle really interesting problems.
CW (08:08):
You were right.
BL (08:09):
Yeah.
EW (08:09):
They didn't have deep neural nets in 1968?
CW (08:12):
No.
BL (08:13):
No, they did not. Not only that, but the computers were quite small -
CW (08:17):
Yeah.
BL (08:18):
- and not very fast. And so this limited greatly what you were able to do.
EW (08:23):
When I start looking at big systems, or even small systems that are complex, I always do block diagrams. That's my initial, "How am I going to make sense of the world," solution.
BL (08:37):
Okay.
EW (08:38):
I mean, that's how I've been doing it. Are there better methods? Do you -
CW (08:43):
Is there a formal theory to modularity?
EW (08:46):
Yeah.
BL (08:46):
Well, there is this thing called computational thinking. And what I tell my students is that you start by inventing abstractions. So you think about data types. You think about functions, that if you had a machine that did all that stuff, this would be the ideal machine on which to build the program to do whatever it is you're working on.
BL (09:15):
You work with that for a while. So you actually write that program. It's just a bunch of comments. And you define the meaning of all the abstractions that you invented. And after you're confident that you have a system that would work, then you pick up one or more of those abstractions that you invented, and you do the whole thing again.
BL (09:35):
And of course you document it. And the document is this thing I call a module dependency diagram that shows what abstractions each piece of the program depends on. So I think that's probably a bit like your block diagram.
EW (09:50):
And when you say abstractions, it's one of those words that people kind of -
CW (09:55):
That's for abstract work.
EW (09:55):
- run away screaming, -
BL (09:57):
Yes.
EW (09:57):
"Oh, my God. Abstractions!" But it's not that complicated of an idea.
BL (10:03):
No, it's not. And for people who work in computing, I think it's a pretty natural idea. So an example of an abstract operation is a routine that would sort arrays. An array itself is an example of a data abstraction. A file is another example.
BL (10:27):
So there are many, many examples of what these abstractions are. And if you're working with programming, you learn about those. And then it's not that difficult to think of other things that are like that.
EW (10:38):
And it isn't just object-oriented programming that has abstractions.
BL (10:44):
No, abstraction is just a basic way in which you build programs. Although I think most programs that are built today are object-oriented just because it's a natural way to think about what's going on.
EW (10:59):
Even working in C on low-level devices, I tend to take an object-oriented approach, because I think about sensors, or buses, or motors, or whatever I'm working on. And those are objects.
BL (11:14):
That's right. That's right. And they exist in all programs,
EW (11:19):
But sometimes figuring out which is an important object is difficult.
BL (11:25):
I think that there's an art to design, and that was the one thing I felt that I could not teach my students. I could tell them what abstractions were. I could give them examples. But coming up with the right abstractions makes a huge difference. And that is a kind of an art.
EW (11:44):
Are there any tips on that?
CW (11:46):
She just said she couldn't teach it.
EW (11:48):
It is an art.
BL (11:51):
I think you practice.
CW (11:53):
Yeah.
BL (11:53):
You look at programs. You see what works and what doesn't work. And maybe some people can do it, and some people can't.
EW (12:01):
And you have the Liskov Substitution Principle, and that has to do with abstractions and being able to reuse subtypes.
BL (12:15):
Right.
EW (12:18):
Is this what you call it? Do you call it the Liskov Substitution Principle?
BL (12:23):
No. What happened was, I defined the idea in a talk I gave around 1986 or '87 and about four or five years later, I received an email from someone asking me is this the correct definition of the Liskov Substitution Principle? So that was the first time I knew there was such a thing as the Liskov Substitution Principle.
EW (12:52):
What was your reaction? What did you say?
BL (12:56):
Well, I was astounded. My reaction was, I looked at whatever it was that was presented and sent back an answer. But it was a big surprise. ... Then at that point I realized that there was all this chatter on the internet where people were talking about the Liskov Substitution Principle and trying to figure out exactly what it was. But it was all news to me.
EW (13:19):
Could you explain it to us?
BL (13:22):
Well, the way that I defined it was, I said, "You have a program, and you've written it in terms of a particular data type. And that means that you assume not only that that data type has certain operations, but that they have a certain behavior."
BL (13:40):
"And you want that program to be able to work correctly, even if it's passed an object that belongs to a subtype of the type that you were assuming. And this imposes certain constraints on the subtype, namely, of course, obviously has to set the same operations that you're expecting.
BL (14:00):
"But they also have to behave exactly the same way that the supertype would behave as long as you're using it in this context of the supertype, and you're not looking at any of the extra behavior that the subtype provides for you."
EW (14:16):
Okay.
CW (14:17):
So a concrete example, if I had a string object that I'd subclassed to be a special type of string with some extra operations, ... a search function should still work on the subclass as well as the superclass.
BL (14:33):
That's right. So the string subtype that you defined might have some extra operations that aren't being used by this program that was written in terms of the supertype, the strings. But it better behave the same with all the operations the string provides so that that program will continue to work correctly.
EW (14:53):
I found this a little easier to understand in its failure. If I have a dime, and I call that a subtype of a coin -
BL (15:02):
Yeah.
EW (15:03):
I want to flip a coin, okay, I can use a dime. But if there is some cubicle form of money or spherical sort of money, and I call that a subtype of a coin, when I flip it, the whole universe crashes.
BL (15:17):
Yes. So I think that what we have there is an example of why it's such an important principle. We write lots and lots of code. It's all modular, so the code is written in terms of other modules and relies heavily on the expected behavior.
BL (15:37):
And if the expected behavior isn't there, then all the code that depends on it doesn't work. And that's what's really important about what you refer to as the Liskov Substitution Principle. Technically it's called behavioral subtyping. Because if you don't obey the rules, your program doesn't work.
EW (15:58):
That seems so basic. I mean, if you don't obey the rules, your program doesn't work.
CW (16:03):
But you have to know the rules.
BL (16:04):
But you have to, yeah.
EW (16:06):
Even with this, I wouldn't call a motorcycle a car. Messing up abstraction is confusing. This seems really obvious. Is it just hindsight?
CW (16:21):
It's not obvious. I don't think it's obvious.
BL (16:23):
Well, at the time that I invented it, it obviously wasn't obvious. And I think that what happened was I had been working on CLU and data abstraction, and I was thinking about it behaviorally. So I would think about a data abstraction. It has a specification. This is how it's supposed to behave.
BL (16:49):
... I had a very clear separation between what a module was supposed to do and how it was implemented. In the object-oriented world, as it existed at that time, it was much more implementation-oriented.
BL (17:08):
And people would talk about subtypes by talking about how the implementation of the supertype was changed in order to build the subtype, because they were working on inheritance. And so I guess that because I was thinking about it from the point of view of behavior, I was able to see this rule that other people hadn't been able to see.
CW (17:31):
What was the state of object-oriented programming in the mid-eighties? Was it Smalltalk was around and -
BL (17:37):
Smalltalk was around.
CW (17:39):
Yeah.
BL (17:39):
And there were a few other languages being looked at like, I forget the names, some version of Lisp and so forth.
CW (17:46):
Right.
BL (17:47):
And people ... were searching for an understanding of what subtypes should be like, but they just didn't understand it. They hadn't quite got there yet. And I happened to start thinking about this because I was giving a talk at OOPSLA, which is the big object-oriented conference.
BL (18:07):
And I decided I better look at what's going on with object-oriented programming. And I discovered they were interested in this idea of subtypes, but they didn't understand what it was.
BL (18:16):
And to me it seemed kind of obvious. You want the subtype to behave like the supertype when used where you expect the supertype. I mean, it is kind of common sense, but for some reason I was able to see it. I don't know why.
EW (18:32):
It is both common sense and yet so much of computer science is being able to figure out which common sense applies and which part doesn't.
BL (18:42):
I guess that's true.
EW (18:44):
At the talk that you gave, did anybody stand up and shout, "Wow, this is the best thing ever," or was it -
CW (18:53):
You've been to technical conferences. Is there a lot of shouting?
BL (18:57):
So honestly I have no memory of this. I think the talk was well received ... I mean, as I said, five years later, all of a sudden out of the blue, I got this email, and meanwhile, I was working on other stuff. I wasn't thinking about it at all. So I don't know. Clearly it had a big impact, because it sort of took off on a life of its own.
EW (19:28):
It really did. And once it came back five years later and people were talking about it, did you revisit it and think about it further or had you kind of moved on?
BL (19:42):
Well, I had moved on, but Jeanette Wing had gotten in touch with me. She was interested in trying to come up with a formal definition of what it was all about. Because what I just gave you was a very informal, sort of intuitive explanation.
BL (19:58):
And so I did do work with Jeanette in the '90s, and we wrote some papers based on that work about, "What exactly is this substitution principle mean if you try to pin it down?"
EW (20:10):
Did you make any refinements that you can explain here, given not an hour's worth of lecture?
BL (20:17):
And the fact that it's a long time ago?
EW (20:20):
Well, that too.
BL (20:22):
Yeah. Right.
EW (20:23):
I don't know. The mid-nineties seems so much closer than the mid-seventies.
BL (20:27):
That's true. But no, I don't think I can. So, sorry.
EW (20:34):
No, no. Don't worry about it.
BL (20:35):
If I went back and thought about it, yeah, I probably could, but I haven't thought about it for quite a while.
EW (20:40):
When we talk about computer science, this is the science part. But there's also this area of, "How do we know which goals, or ideals, or methodologies work best?" Is there some metric that says this is better other than common sense?
BL (21:03):
I'm certainly not aware of metrics. There was quite a bit of work on metrics in the '70s and '80s, and I think it never got anywhere. But in truth, most of my research, starting in the '80s, has been in distributed systems. And I haven't been following the research that goes on in what's called software engineering or programming methodology.
BL (21:33):
And so I can't really answer the question, whether there are metrics. I can tell you that the proper use of the Liskov Substitution Principle is not something that can be enforced by a compiler. And so people have to apply it on their own and think about it.
BL (21:56):
It would be better if there were a way that it could be enforced. And then when somebody makes a mistake and doesn't quite get it right, rather than having to find out later because some module breaks, you could find out just when you ran your program through the compiler.
EW (22:13):
I have been thinking for a while now that I kind of need, I think a friend called it a daily devotional for software engineer, something that every day would remind me, "Oh, the Liskov Substitution Principle says this and don't forget about it."
EW (22:29):
And then the next day, maybe "Here's a good don't forget to have good posture as part of good software engineering," and all of the things that I know that I learned, that I read about. But then when I'm sitting at my keyboard trying to get things done, they don't always sink in.
BL (22:49):
Yeah. It's tough. That's why it would be nice if the compiler could enforce it.
EW (22:56):
That is true.
BL (22:57):
Yeah.
EW (22:57):
I don't worry about semicolons destroying my programs anymore.
BL (23:01):
Right. And you probably don't worry so much about data types either. If you have a strongly typed language, the compiler can enforce the types themselves. And so you don't have to worry that, "I'm expecting a particular type and something else comes in." But they've made a lot of progress in program verification. So I suspect that tools are on the way.
EW (23:25):
... Actually, when did you start working on CLU?
BL (23:33):
Well, I invented data abstraction. I did this work with a friend, a colleague of mine, Steve Zilles. And this was in 1972, '73. And so that was the first step, was just this idea of the data abstraction, which, people didn't understand what it was.
BL (23:52):
And that in fact, in my opinion, a bigger contribution than the Liskov Substitution Principle. Because without the notion of data abstraction, we don't have the modules that we know today.
EW (24:05):
Wait a minute, stop there. "I invented data abstraction"?
BL (24:09):
Yeah.
EW (24:10):
I mean, this seems -
CW (24:12):
Like she said, it's more important.
EW (24:13):
It is way more important. And I mean, that's amazing. And I was like, "Oh, come on. That's been around since computer started." And then you said 1972, I'm like, "Okay. Yeah."
BL (24:24):
Yeah. Yeah.
CW (24:25):
So let me think, '70s, there would be Fortran then, right, and COBOL, and -
BL (24:31):
There's no data abstraction there.
CW (24:33):
No data abstraction. Okay.
BL (24:35):
No.
CW (24:35):
Okay. That is a big leap.
BL (24:38):
Yeah, it was a big leap. And when I got the Turing award, I went back and I read a lot of the papers that I had read at the time about program methodology. And what I see in retrospect is that the idea of data abstraction is lurking in those papers. It's just that nobody quite managed to pull it out and say what it was.
BL (25:00):
And I think if I hadn't done it, somebody else would've done it at some point not too far after when Steve and I came up with that original paper. But it didn't exist before then.
CW (25:16):
And so what was the impact of that? How quickly did that start getting adopted?
BL (25:21):
Oh, that had a huge impact in the sense that, I mean, we wrote a paper on it, everybody who read that paper knew this was a really important idea, because people had been groping, they wanted to figure out how to do modular program construction. And this gave them a way of doing it. So it had a big impact.
BL (25:41):
And what I did next was I worked on CLU, and that took several years, because having an idea of what a data abstraction is, well, that's just an idea. And figuring out the rules and getting it into a programming language so people could use it, that was the next important step.
BL (26:00):
So that's what CLU was all about, figuring out what it really is, "Here's how you write programs with it." It actually performs okay. You can really use it in practice.
EW (26:15):
So CLU, what is it based on? What is it like? What would I use it for?
BL (26:21):
CLU had something called a cluster, which is kind of like a class, except that it had complete encapsulation. So the implementation that was present inside a cluster was not visible to any code. There was no way that code outside the cluster could access the details of how you represented the data type.
BL (26:45):
And what happened with CLU was, finally in the '90s, Java appeared. So if you think about Java, Java picked up the ideas of data abstraction and strong typing from CLU, and it picked up the idea of inheritance from Smalltalk, and put them together.
BL (27:06):
And then it moved into the mainstream of computing. So it was a research project. And research often takes many years before it moves from the research world to the real world.
CW (27:18):
Right.
EW (27:20):
On one hand, I'm sitting here thinking we've always had these things. We've always had data abstraction. I remember when inheritance was the big new thing. And it was super cool, and everybody should use it. And yet it hasn't been that long.
BL (27:39):
No, it has not been that long.
EW (27:42):
The idea that the concept of data abstraction, which now we build upon, we're like, "Okay, objects everywhere."
BL (27:49):
Yep.
EW (27:51):
What do you think is the next thing?
BL (27:54):
Well -
CW (27:56):
Invent something new.
BL (27:59):
No, I mean, I can't answer that question.
EW (28:03):
Anyone who can, please contact the show.
CW (28:05):
No, they're too busy inventing things.
BL (28:09):
Yep.
EW (28:10):
You mentioned you won the Turing Award, and that is significantly different than the Turing Test.
BL (28:17):
Yes, significantly.
EW (28:19):
And you won it before it came with the lovely cash prizes.
BL (28:23):
Oh, no. I got quite a bit of money.
EW (28:25):
Oh, that's nice.
BL (28:27):
Yes. I mean, it's the award's gotten bigger, but it was still significant.
EW (28:32):
And do they award it to a career, or to a particular idea, or to a series of papers?
BL (28:41):
That's a good question. There has to be a significant contribution that you can point to. So it's not to somebody, "Oh, they've had a distinguished career," you can sort of point out, but nothing sort of sticks out. If you look at all the awards, there's always been a specific thing that they got the award for.
BL (29:00):
So I got the award for the work on data abstraction and the Liskov Substitution Principle, and also later work that I did on replication techniques. But other examples of awards are, Ron Rivest got one for inventing RSA, and most recently, Mike Stonebraker got one for all his work on databases. So you have to point to specific contributions.
EW (29:26):
And how did that change your career?
BL (29:29):
Well, I don't think it did change my career, but it's very nice to be recognized.
EW (29:35):
Oh, absolutely. Do you think that if the Liskov Substitution Principle had ended up being called behavioral typing, you would've gotten as much credit for all of this?
BL (29:49):
I think that's an interesting point, because having your name attached to something does make your name recognizable. Data abstraction doesn't have my name on it. So, yeah. But on the other hand, if you work in research, the things that you invent are known to people who are working in the area.
EW (30:12):
Yeah. And as you said, data abstraction is kind of a bigger contribution as a whole.
BL (30:22):
Although, it is very closely tied to the Liskov Substitution Principle, because it does talk about how you can arrange data types in a hierarchy and have it make sense.
EW (30:36):
Who were your biggest influences as you decided to go into computer science and throughout your career?
BL (30:46):
Well, that's a very hard question for me to answer, because there's no particular person that I can point to. I think that, as I said, computer science was in a very early stage, and I was just reading what people wrote, and thinking about the problems I thought were important. And it wasn't like there was some specific person that I felt was an influence.
EW (31:20):
Was there some reason you decided computer science was the path for you?
BL (31:26):
Yeah. I got my bachelor's degree at Berkeley in math. I decided that I wasn't ready to go to graduate school so I should get a job. I didn't know there was such a thing as a computer at that point. But I was offered a job as a programmer.
BL (31:44):
And as soon as I started working in the field, I knew it was the field for me. It's a wonderful combination of math and engineering. And it sort of fit my skill set, and I really enjoyed it.
EW (32:05):
But then you went back to school and got a PhD.
BL (32:08):
Well, I worked for a couple of years, and I decided that I was essentially self-taught. My first day on the job, they handed me a Fortran manual, and they said, "Write a little program to do something."
BL (32:23):
I forget what it was. So I had to learn it all by myself, and part way through this two-year period, I decided that maybe I could learn faster if I went back to school.
EW (32:34):
Were these the days of punch cards?
BL (32:37):
Oh yeah. Punch cards, and the computer room where you would submit your deck, and then maybe you'd get it back tomorrow or the day after.
EW (32:46):
It's kind of hard to really think about abstraction when your compiles take a couple of days.
BL (32:53):
Well, there's one advantage to that, which is that you have to think very carefully about what you're going to accomplish in a run. So one of the things I used to tell my students was that, "You need to think carefully about what test cases you want to run and what you plan to learn from them." Because you can waste an awful lot of time sitting at the computer, just doing random stuff.
EW (33:16):
Monkey typing.
BL (33:17):
Yeah.
CW (33:17):
Which is how most development is done now.
BL (33:20):
That's right. And well, I'm not so sure about that.
CW (33:23):
Yeah.
BL (33:23):
But I think that there was, there was a discipline in, this was your shot. And so you better think carefully about what you were going to accomplish.
CW (33:30):
Yes.
EW (33:32):
Is it possible to have too much abstraction? How do you decide when you've had too much?
BL (33:37):
I think that there's an art to designing an abstraction. It needs to be as simple as possible, but it also has to have all the right stuff in it. And again -
EW (33:53):
This is an art. Yes.
BL (33:54):
Yeah. So you need to think about, "What is this abstraction being used for? What operations does it need to have? Is it really essential that it had this one, which is sort of a little change to something that's already there," or could you get by without it?
BL (34:08):
And it has to be what we used to call complete, so you can do everything with it you need to do. But there's no point in getting it over elaborate, because that just makes it confusing.
EW (34:20):
It means you write code you didn't have to write, and that's usually money down the drain.
BL (34:27):
... I mean, the other thing is, the process of design has to stop. So you have to be making progress.
EW (34:38):
So you were programming, and you enjoyed it. And you went to get a PhD, and then you went to be a professor, and do research, and teach.
BL (34:48):
Well, actually I first went and worked in research at industry for four years.
EW (34:54):
But then you left that. And I mean, programming and being a professor seemed like pretty different jobs. I mean, one's a very introverted job, and one has students asking you questions all day long.
BL (35:09):
Well, of course, when you're working on large projects, you're always working with other people.
EW (35:14):
That is true.
BL (35:15):
So it's not as introverted as all that. But as I said before, I changed from AI to systems. And those four years when I worked in industry gave me space to make that change.
BL (35:32):
And not only that, but it was during my work in industry that I started working on what was called the software crisis, which was that programs didn't work.
BL (35:43):
And millions of dollars and hundreds of man years would be wasted in project after project, and then they'd have to announce a failure. And that's what I started to work on that led to the ideas of data abstraction.
EW (35:58):
I don't follow.
CW (35:58):
I've never heard that term before. This is very interesting.
BL (36:01):
Yeah, no -
CW (36:01):
So we probably should resurrect it.
BL (36:06):
Yeah, well, actually, and even up into the '80s, there were still, in the newspapers, reports of failures of software. So it was a really big problem for many years.
CW (36:21):
Was that with certain classes of applications or - ?
BL (36:26):
No, it was across the board. It was just that people didn't know how to build big systems.
CW (36:31):
Right.
BL (36:31):
Because they didn't understand how to do modularity.
BL (36:35):
And that's where data abstraction came in that gave you an idea of a pretty big powerful module, but one that was separated from everything else and had a well-defined behavior.
CW (36:45):
So would you say that the computers got more powerful, but our thinking about how to build larger systems didn't quite keep up with that at that time. Is that sort of what happened?
BL (36:55):
So I used to think about software versus electrical engineering with a little bit of envy, because when you're doing stuff with circuits, you have to have well-defined interfaces. And you have to sort of break things up into pieces, and they have to be independent. But with software, it's completely open. There's no rules.
CW (37:19):
Yes.
BL (37:20):
Nothing is enforced. You have to make it all up yourself. So we had to figure out what those rules ought to be and how to define them.
CW (37:30):
And with electrical engineering, at least you have physics, sort of.
BL (37:33):
You have physics, right. And you've got wires, and you can't have too many wires. But with programs, they used to call them bowls of spaghetti. They were just all a mess with no notion of locality and modularity.
EW (37:51):
And we think about our programs now. I mean, we talk about spaghetti code, and I've definitely seen programs that seemed impenetrable and unmanageable. But they're still using libraries, and modules and data abstraction.
CW (38:04):
It wouldn't even be possible -
BL (38:07):
Yeah.
CW (38:08):
- without that. Yeah. They'd be -
BL (38:11):
Right.
CW (38:12):
So we still have messy code, but it's a different kind of messy now.
BL (38:15):
Well, I think that you just have to keep plugging away at it.
CW (38:18):
Yeah.
EW (38:20):
You mentioned testing as an element in this.
BL (38:26):
Yeah.
EW (38:26):
And there's this Agile methodology. Were you involved? And I think the Liskov Substitution Principle mentioned in much of the Agile methodology.
BL (38:37):
It could be, but I don't actually know much about that. Because as I said, I had moved over into distributed systems, and I wasn't paying any attention.
EW (38:45):
Cool. What do you do in distributed systems?
BL (38:49):
Well, I started working on replication in the '80s. At that time, ... there could be a program that had many servers connected by an internet, and people were starting to think about using remote file servers. And it occurred to me at the time that when you had all your files on your own machine, if your machine was down, you couldn't use them.
BL (39:25):
But if it was up, you knew you could get access to your files. But if your files were sitting on a remote server, then even if your machine was up, you might not be able to access your files because the internet wasn't working, or the computer where your files were stored was crashed. And so I started to work on replication techniques that would provide better behavior and -
EW (39:52):
You invented Dropbox.
BL (39:54):
Well, no. I invented something called viewstamp replication, which is also called Paxos. And it's a replication technique that allows continued service even when some computers have failed by crashing. And then later I worked on a more complicated kind of failure called a Byzantine failure where the computer is still running, but it's misbehaving.
BL (40:23):
And so you might say to it, "Here, store this piece of data for me." And it comes back and says, "Okay." But in fact, it's lying and at some time in the future might decide just to forget about you altogether.
EW (40:37):
I feel like I've met these computers.
BL (40:40):
Yeah, well, actually, we meet them all the time, because when somebody breaks into your computer and brings it down, they can cause it to behave in a Byzantine way.
EW (40:52):
Yes.
BL (40:53):
Yeah.
EW (40:54):
This is all very much cloud computing, but this was the '80s?
BL (40:59):
Well, the viewstamp replication was in the '80s. The Byzantine fault tolerance was in the late '90s.
CW (41:07):
We had networks and computers back then. I worked on networks in the '90s.
EW (41:11):
I know.
BL (41:12):
Yeah. Yeah.
CW (41:12):
They just started calling stuff cloud. That's all marketing.
BL (41:14):
Yeah.
EW (41:16):
That's true.
BL (41:16):
Yeah.
CW (41:16):
We've been doing this forever.
EW (41:20):
In your CV as of 2009, you had 137 papers and 102 reports. Which one was your favorite?
CW (41:33):
Oh, geez.
BL (41:34):
Well, I'm not sure that I have a favorite, but I think some of those papers are more important than others. So the original paper that introduced data abstraction, that was a very important paper. The work I've just been describing on viewstamp replication, and then Byzantine fault tolerance, there are quite a few papers in there I like. I confess.
EW (42:00):
Are you working on new research these days, or are you enjoying the life of retirement?
BL (42:06):
I am still working part-time on a couple of different projects that I work on with colleagues now. Because I'm semi-retired, and I don't have any students anymore, so, yeah. It's fun research.
EW (42:23):
Oh, yeah.
BL (42:23):
Yeah.
CW (42:25):
Have things gone the way you expected, or did you not think about things that way when you were doing research?
BL (42:35):
I would say that I'm somewhat dismayed by the state of the internet these days, and I hope that we will be able to come to grips with the not-so-good uses of technology that we all see around us. I didn't foresee that stuff, although when you think about it, I think I and the research community were maybe awfully naive.
CW (43:10):
I think a lot of folks working in tech were -
BL (43:13):
Yeah.
CW (43:13):
- with the exception of maybe a couple sci-fi authors.
BL (43:17):
Yes, but of course sci-fi authors, yeah. I mean, it's interesting where we are now, and I worry about what's going on with artificial intelligence. And I worry about fake news and a lot of the misuses that are happening on the internet. We have to come to grips with this new technology and figure out how to keep it under control.
EW (43:44):
Which parts of artificial intelligence concerns you the most?
BL (43:48):
Well, I mean, many things are good, so voice recognition is good and so forth. But I think AI can produce fake news.
EW (44:03):
Yes, definitely.
BL (44:04):
... It used to be seeing is believing. I don't know that seeing is believing anymore. So I worry about stuff like that. And then there's some really bad stuff like robotic warfare and stuff like that. So there are many things about computers that are wonderful.
BL (44:25):
In fact, I went to see Little Women the other day with my granddaughter and my daughter-in-law. And Jo, the character in the movie is writing a book on paper with a pen. And I'm thinking, "Wow, writing was so much harder then than it is now." I mean, just think about what was involved and what happens when you want to make a change, how much labor was involved in doing stuff that's really pretty easy to do now using a computer.
CW (44:58):
We thought we were pretty cool when we invented white-out.
BL (44:59):
Yeah, white-out was good.
CW (45:01):
That was a major advance.
BL (45:01):
It was. And I remember when I still had a secretary who was typing stuff for me, and she was a genius at cutting and pasting so you didn't have to retype pages. You could actually move them around. But what you can do just by working online with an editor is really amazing.
EW (45:24):
It is amazing that we say cut and paste for code. I mean, Control+C, Control+V. It's what we call them, but it actually used to mean cut and paste.
BL (45:34):
Cut and paste. That's right. Yes.
EW (45:37):
Are there science fiction concepts that have come true over your career that you find very interesting?
BL (45:45):
Well, I don't read science fiction, so I don't -
EW (45:48):
Oh, okay. That was a terrible question then.
BL (45:52):
Well, one that doesn't apply to me. Yeah.
EW (45:56):
What do you hope for the future? What do you think will change?
BL (46:00):
Well, as I said, I hope that we figure out how to deal with this new technology in a way that's beneficial for mankind and keeps some of the more criminal elements under control. So that's my hope is that we can do that.
BL (46:19):
And I think we probably need to teach our students more about ethics. And when you're designing software, you can think about what's good about it, what it's going to do that's beneficial, and not just sort of blindly go in creating something that can be immediately misused in a bad way.
CW (46:42):
I think that's something that is just starting to be talked about extensively -
BL (46:46):
Right.
CW (46:46):
- is including ethics in CS and engineering curricula -
BL (46:50):
Right.
CW (46:50):
- which would be great. Yeah.
BL (46:54):
Yeah. Yeah.
EW (46:55):
Yeah. We do need more ethics, and we need more continuing education. Do you have any good resources for people who have heard more about data abstraction or abstraction in general than they usually do and want to read something?
BL (47:16):
Well, first of all, there's a lot of online stuff, education online .and courses are offered at MIT and at many other places. And so that's a very good way to become educated about things like how do you design and stuff like that.
EW (47:41):
Fair enough. That is the good part of the internet though.
BL (47:44):
Yeah, that's right. There's a lot of good stuff. It's just that there's also a lot of bad stuff.
EW (47:50):
Barbara, are there any thoughts you'd like to leave us with?
BL (47:53):
Well, I just thought I would tell you a story, because it relates to the stuff we were talking about earlier about how, "Oh, yeah. This stuff really didn't happen all that long ago." So when I got the Turing Award, one thing I discovered was that my students in fact did not know that there was a world in which there was no data abstraction.
BL (48:17):
But also, my husband was online every day, reading all the chatter. People were talking about how I got the Turing Award and so forth. And one day he saw a comment from somebody that said, "Why did she get the award? Everybody knows this already," something like that. And it wasn't meant in a kind way.
CW (48:44):
Rig ht.
BL (48:45):
But it was actually an incredibly nice thing, because it was true. The work that I had done in the '70s had become so embedded in computer culture that everybody did know it by then.
CW (49:03):
It just emerged fully formed in the world.
BL (49:05):
Right. But I mean, it's wonderful when your work has that kind of impact ...
CW (49:10):
Yes.
EW (49:12):
It becomes the water that the fish just don't even know exists.
CW (49:15):
Right.
BL (49:16):
Right. Yeah.
EW (49:18):
Our guest has been Professor Barbara Liskov, Institute Professor, Department of Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.
CW (49:29):
Thanks for joining us again.
BL (49:31):
Thank you.
EW (49:33):
Thank you to Christopher for producing and co-hosting. Thank you to our wonderful patrons for Barbara's mic. And thank you for listening. You can always contact us at show@embedded.fm, or hit the contact link on embedded.fm.
EW (49:45):
Now a quote to leave you with, from Dijkstra, in his 1972 Turing Award lecture. "The major cause of the software crisis is that machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem. Now we have gigantic computers, programming has become an equally gigantic problem."
EW (50:19):
Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. If there are advertisements in the show, we did not put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.