Oral-History:Barbara Liskov (2001)
About Barbara Liskov
Barbara Liskov was an innovator the field of programs that access and analyze databases. She graduated from the University of California at Berkeley with a degree in Mathematics. After working for a couple years as a programmer for the Mitre Corporation and a Harvard computer research lab, she returned to school and received her Ph.D. from Stanford University in 1968. She started teaching at MIT in 1972 and is the current Ford Professor of Engineering.
Major projects credited to her include Venus, CLU, Argus, and Thor. In this interview, Liskov goes into the technical specifications of all these projects. Additionally, she discusses her time at Stanford University and she ends the conversation with thoughts on how to balance career and family.
Liskov was previously interviewed in 1991 This interview focussed on NSF funding for her projects at MIT, including CLU, Argus, Mercury, Thor and Harp.
About the Interview
BARBARA LISKOV An interview conducted by Janet Abbote for the IEEE History Center, 8 February, 2001.
Interview #609 for the IEEE History center, The Institute of Electrical and Electronic Engineers, Inc.
Copyright Statement
This manuscript is being made available for research purposes only. All literary rights in the manuscript, including the right to publish, are reserved to the IEEE History Center. No part of the manuscript may be quoted for publication without the written permission of the Director of IEEE History Center.
Request for permission to quote for publication should be addressed to the IEEE History Center Oral History Program, IEEE History Center, 445 Hoes Lane, Piscataway, NJ 08854 USA or ieee-history@ieee.org. It should include identification of the specific passages to be quoted, anticipated use of the passages, and identification of the user.
It is recommended that this oral history be cited as follows:
Barbara Liskov, an oral history conducted in 2001 by Janet Abbate, IEEE History Center, Piscataway, NJ, USA.
Interview
INTERVIEW: Barbara Liskov
INTERVIEW: Janet Abbate
DATE: 8 February, 2001
PLACE: Barbara Liskov’s office in Cambridge, MA
Family Background
Abbate:
I’d like to start out with your family background. Can you tell me where you grew up, and what your parents did for a living?
Liskov:
I grew up in San Francisco. My father was an attorney. My mother was a housewife. I was the oldest of four children—and actually, the children came in two sets, so there was my sister and myself, and then seven years later there was another pair, my brother and my younger sister. So I was the oldest child and the oldest daughter—when there was no son for quite a long time.
Abbate:
Do you think that had some influence in terms of their ambitions for you?
Liskov:
I don’t know. What I’ve read is that it does make a difference, yes.
Abbate:
Did your parents encourage you to get involved with math and science at all, or was that your idea?
Liskov:
I don’t recall them encouraging me, but I also don’t think they discouraged me. So I don’t think I ever had a message that said, “Oh, you really shouldn’t be interested in that, because it’s not suitable for a woman.” On the other hand, there was also never any message that I should think about a career.
Abbate:
Really?
Liskov:
Yes.
Abbate:
Can I ask you when you were born?
Liskov:
1939. So this was not uncommon in that generation.
Abbate:
Were you particularly drawn to math or science in school, or before college?
Liskov:
Yes. I absolutely was always very interested, especially in math, and I always took the highest-level courses. But I always tried to keep a very low profile, so that people wouldn’t notice too much what I was doing.
Abbate:
Was that because you thought it was unusual for a girl?
Liskov: It was definitely unusual. I don’t really remember clearly, but I’m sure that at the end of high school I was the only girl taking advanced [math]—it was pre-calculus in those days. And you know, I’ve always felt that one of the reasons why I was able to proceed in this direction, when it was definitely not something that women were supposed to do in those days, was that I paid very little attention to what other people thought about it. So it’s odd in retrospect that I don’t remember what my classes were like [in terms of gender balance], but I think that’s because I just didn’t care.
So one of the things I’ve always been curious about is: What was it that enabled me to do this? And what didn’t allow some other women that I knew to do it? And what other kinds of ways did people have of coping with that kind of negative feedback—which I’m absolutely certain was there; I just was oblivious to it. Except for this: “Don’t make a big point of it,” because it was definitely not the thing to do.
Abbate:
Did you have any mentors or teachers who encouraged that? Any female math teachers, or anyone?
Liskov:
I don’t remember anything like that.
Abbate:
So it was just you.
So you probably didn’t use a computer until college?
Liskov:
Oh, I didn’t get into computers until after college.
Advanced Schooling
Abbate:
For college, you went to Berkeley, and majored in math?
Liskov:
Yes, right.
Abbate:
And that would have been . . .
Liskov:
I went in in ‘57, and graduated in ‘61.
Abbate:
You already knew at that point that you wanted to major in math?
Liskov:
Actually, I started off majoring in physics, and then I decided that physics was too hard, or I liked math better, or something. So I ended up with a major in math and a minor in physics.
Abbate:
Have you used the physics?
Liskov:
Not at all. And most of the math I don’t use, either: because computer science is all discrete math, and of course, as a math major, I took a lot of other kinds of math as well.
Abbate:
But it does seem to be women who are math-oriented who end up in computer science.
Liskov:
Well, there’s definitely a strong correlation between computer science and discrete math and logic.
Abbate:
Your experience at Berkeley: Was that a good experience?
Liskov:
Well, I had a wonderful time. I loved it! I found the academic material very challenging. I was an off-again, on-again student; some semesters I worked, and other semesters I kind of goofed off. I don’t think that, academically, I received any particular encouragement. I was, again, the one woman—or maybe the one of two women—in every math class, which was pretty intimidating, and I didn’t like to talk up in class. In fact, for years—even today—I think I still have this problem: I don’t really want to ask a question in a seminar. It took me a long time to realize that if I had a question, I probably was not the only one. But this is very deeply ingrained; and actually I think this is a way in which I was socialized that’s not been beneficial, relative to the way that men are socialized. You know, to be more accommodating; not [to ask questions]. And then I think what happens is that in some sense it spills over into the other direction: so I’m too passive, and then maybe I become too aggressive.
Abbate:
Interesting—although the men also seem to not want to ask questions, maybe for different reasons.
Liskov: Well, some don’t, but some of them are very good about it. I have trouble speaking up, especially being the first one to speak up. So I kept a very low profile in my classes.
Early Career
Abbate:
You got a Ph.D. from Stanford. Was that directly after college?
Liskov:
No, it wasn’t. What happened was, when I was a senior in college, I applied to graduate school, and I actually got into Berkeley math, but I decided that I wasn’t ready to go on. I didn’t feel committed enough to work that intensely, so I decided it was probably a good idea to take some time off. I had a friend who was coming to Boston, so I decided to come to Boston with her and get a job here. When I went to look for a job, I couldn’t get an interesting job in math, but I got an interesting job as a programmer. So that’s actually how I got into computers. [laughs.]
Abbate:
I hear that story a lot.
Liskov:
Yes.
Abbate:
So, you’re in Boston, and this is . . . ?
Liskov:
1961 to ‘63, I was in Boston. The first year, I worked at the Mitre Corporation, just as a lowly programmer. They had two different levels of hiring, and I was at the lower level. After a year at Mitre, I saw an ad for a programming position at Harvard, which I thought was appealing. For one thing, I was living in Cambridge; and it was to work on a language translation project that sounded kind of interesting. So I applied for that job and I got that job, and I left Mitre—although they, at that point, immediately offered me a raise and a better position and so forth. I mean, even at the time, it was clear to me that the men they were hiring were coming in at better positions than the women. But of course, that also is the way it’s played in industry: if you don’t ask for what you want, you don’t get it. And I was very naive.
Anyway, I worked at Harvard on the language translation project for a year—and again, I was just a programmer. I wasn’t doing any of the research. I was just maintaining a program that was supposed to be able to parse sentences.
Abbate:
I think I’ve heard of that. Was that translating Russian into English?
Liskov:
No. At that stage, what they were working on was: they were only trying to parse sentences. There are lots of sentences that are grammatically ambiguous, so they had a program that would find as many possible interpretations for a sentence as it could. And although this was all they could do in this program, they never lost the belief that they’d have language translation cracked in just a few years.
Abbate:
Interesting.
Liskov: But that was how it was then. People didn’t understand how hard AI was, and they really thought that with just a few years’ work, everything would be taken care of.
Abbate:
Who was running that program?
Liskov:
That was a fellow named Tony Ottinger, and Susumo Kuno was actually the person, I think, who was the primary researcher on the project. And Sheila Greibach was at Harvard—she was a graduate student there. I don’t if she’s on your list.
Abbate:
No, I don’t know her. What did she do?
Liskov:
She got a Ph.D. in—I think she isn’t exactly a computer scientist; she’s more of an applied mathematician. And I couldn’t tell you what her work has been on; but at the time I was at Harvard as a programmer, she was a graduate student. She was not associated with this project, but somehow or other I knew about her.
Abbate:
And her last name is?
Liskov:
Greibach: G-R-E-I-B-A-C-H. I don’t remember—I think she might have ended up at some place in the Midwest, but I don’t really remember.
Abbate:
Okay.
So: let me step back a little. The first time you used a computer would have been at Mitre?
Liskov:
Yes.
Abbate:
What was that like? Was it fun; did you like it?
Liskov:
Oh yes, it was great. It was clear I had a tremendous aptitude for it, and I wouldn’t have ever probably moved into that on my own if it hadn’t happened this way. So I sort of stumbled into this field that turns out to be very congenial for me.
Abbate:
Did it seem like this was sort of a man’s area? Or did it already seem like there were lots of women?
Liskov:
Oh no, at that time, there were a lot of women in the area. It changed later. At that time, when there was no particular training you could have to be a programmer, and they were hiring anybody that they thought could manage it, they were hiring a lot of women. Maybe not at the top-tier positions, but . . .
Abbate:
So your first experience with a computer, [you were thinking], “This is something I can do. This is something I like. This is something that lots of women are doing”? So there was kind of an immediate comfort with that?
Liskov:
I don’t know that I paid that much attention to this ‘woman’ thing.
Abbate:
But there wasn’t a message that it wasn’t something you could do?
Liskov:
One of the things I noticed, however, was how sexist the language was.
Abbate:
The computer language?
Liskov:
Absolutely! I mean, they would talk about “penetration,” and . . . I can’t remember all the terminology, but I remember being struck by it at the time, that they used all these sexual terms for things that were going on in programs.
Abbate:
Wow. So these weren’t military terms, but specific to programming?
Liskov:
Oh, no. I mean, if you think about electrical engineering, they have the same thing going on there, with the “male” and “female” connections and stuff like that—which I didn’t know anything about at that point, because I hadn’t taken any double-E. It just sort of struck me in passing.
Abbate:
Interesting. I wonder if I could get hold of some old manuals for those . . .
Liskov:
I don’t think it has changed. I think I’ve just become used to them as technical terms. But at that time, it was all new, and so things struck me that I might not notice today.
So, no: I felt that it was something I could do. I wasn’t committed to it, but it was a good job. The job at Harvard was even better, but I wasn’t that focused on a career at that point. I was having fun!
Abbate:
Did you think you were going to go to grad school eventually? I mean, you’d already . . .
Liskov:
I think that I must have had it in the back of my mind, but it wasn’t very conscious. I was thinking this was sort of an interlude when I would try to figure out what I wanted to do, but I wasn’t making any statement about where I was going. I just thought of it as a step along the way, and I’d figure out later what the next step would be. I always felt that maybe it was an advantage being a woman, in that respect, because I didn’t feel a tremendous pressure to find a career; so I felt free to do what was, in a way, a very frivolous thing: just to get a job and focus on your social life.
Abbate:
Interesting.
What was the next step, after Harvard?
Graduate School
Liskov:
When I was at Harvard, I decided to go back to graduate school, and I think what caused me to do that was that I felt that I’d had enough of this. I actually applied to go back in math. So I reapplied at Berkeley, but they didn’t accept me this time—probably partly because I didn’t actually know enough to send them a letter telling them that I wasn’t accepting their offer the previous time! [laughs.] And so then I applied to Berkeley in statistics and to Stanford and Harvard in computer science, and I got in all those places. I didn’t think to apply to MIT because to me, MIT was a very anti-feminine place to be. I did decide not to do statistics, and to stay with computer science; and I went back to California, because I thought it was time to go back to California. So I went to Stanford. [laughs.] So that’s the random way in which I ended up where I was.
Abbate:
Logical enough.
So: you’re at Stanford, in computer science. Were there a lot of other women there?
Liskov:
Oh, no; absolutely not. There was nobody. When I went to Stanford, there wasn’t even a department yet; it was just sort of a program.
Abbate: That’s in ‘64?
Liskov: ‘63. I went there without any financial support, because I didn’t even know there was such a thing. When I arrived, my first day, I was walking up the stairs and I met John McCarthy—he was either just starting or he’d been there a year—and I asked him if he had any money, and he said “Yes.” So that was how I ended up working with him, and working in AI! [laughs.] Of course, AI was a natural thing for me to work in, given the language translation stuff, but it was really very accidental.
There were no women there the first year. Susan Graham started at Stanford either in ‘64 or ‘65, I forget; and there was another woman that came in when Susan entered. But prior to that, there were no women that I can recall. But it wasn’t a very big program, either.
Abbate:
Did it start officially in ‘65?
Liskov:
Yes. In ‘65 they became a department, and they had their first set of exams. I took the first set of exams; there were seven people who took them, and four of us passed. I can’t remember who the three that failed were. But they were all men except for me. I can’t remember if that was ‘65 or ‘66.
Abbate: So your area was AI?
Liskov:
I was in AI, right. I think it was pretty apparent to me within a very short period of time that AI was not really my field, because along the way I was doing other stuff—I started to do some programming language stuff—and I really had more aptitude for that. But I stuck with the AI, because it just seemed to me like that was probably the straightest path through the program. What’s odd in retrospect is that there is more systems-y stuff going on in AI, but I never moved over and tried to work on that side of it, which would have been much more congenial. It’s not that AI isn’t interesting; I just felt that it was so hopeless! [laughs.] The problems were so hard, and the stuff that you could do at that point was so limited. It’s come a long way.
Abbate:
And you, I guess, had seen some of the practical side of those problems before you got there.
Liskov:
Well, what I really meant was that it was hard to know . . . The kinds of things people were accomplishing were pretty limited. I did my thesis on chess endgames, and I wrote a program, based on a heuristic that John McCarthy had in mind, that was able to actually win certain endgames. But to me, that wasn’t really exciting. I had tried earlier to do some more interesting work in planning, but nobody was getting anywhere in planning in those days. So I felt like there was a barrier there. As soon as I left Stanford, I switched over into systems.
Abbate:
What kind of computers were you using at Stanford, at that point?
Liskov:
Oh, it was a B5000; Burroughs 5000. They didn’t have PCs or anything like that. There were just the big mainframes, and when I first got to Stanford, it was all punch cards. I remember in some of the classes that the whole class would get together in the machine room, and we’d all be feeding our programs through. Of course, since it wasn’t interactive, it was very slow to get feedback. In a typical way that you’d run things then, you used to submit your job, together with the tests that you wanted to run, and then you might have to wait a day before the answers came back; so it was very slow. So we used to run the machine ourselves at night; that way we’d get much faster turnaround.
Abbate:
Interesting.
Liskov: Then toward the end, there was an AI lab there, and we actually had terminals, and so there it was already interactive computing. It wasn’t at the stage yet where you would ever think about writing a thesis online. But you could write your programs online; you could actually run the tests online, so you could do debugging online; and that was certainly much better than having to submit a job and wait a day to get the answer.
Abbate:
I wonder: Did your own experience with programming give you a sense of the need for better programming languages?
Liskov:
You mean, What is it that got me into designing programming languages? [laughs]
Abbate:
Well, yes, indirectly.
Liskov: No, I don’t . . . When I worked at Mitre, I used FORTRAN—which is truly awful. Then I went to Harvard, and I was working in machine language, which was extremely valuable, because it gives you a really good sense of how the machine is actually working. So I think that was really a very important experience. The other thing that was interesting there was: I was maintaining a huge program—which was also really good experience for coming to grips with the realities of programming—and this was not a reentrant program; it had certain instructions that would modify certain other instructions to make the program run faster. People used to do things like that; I don’t think they do it anymore. So it would be optimizing a branch away, because you knew up here at this point in the code that that was the right thing to do, but then you’d better be careful to change the instruction back!
Abbate:
I haven’t heard of that.
Liskov:
Yes, well, that was how people did things at the time.
Abbate:
Sounds like a black art!
Liskov:
Yes, it was! So I learned a lot of little programming tricks. And that one, I thought right from the beginning, was truly not a very good one, because it’s so fraught with error. The reason it’s called “non-reentrant” is because, if you try to use that block of code from two different places, you clearly [will have a conflict]. You can’t be running two computation threads in that block of code, because they’re clearly going to get in each other’s way, since they’re using the same code and it’s being modified. So that was a really bad idea that people used to do, though it certainly did speed things up.
And then, when I went to Stanford, I was using LISP.
Abbate: Oh, sure.
Liskov:
I think mainly what I got out of all this was a pretty broad introduction to different programming languages. At that time, Don Knuth was working on parsers, so parsing was a big issue at that point. People were talking about “precedence grammars”—I mean, this is really old stuff; I’m trying to tell you how long ago it was! PL/I, I guess, was designed while I was a graduate student. I certainly didn’t know about it then; maybe [it was designed] even later.
After Stanford
Abbate:
You got out of Stanford in the early '70s?
Liskov:
'68.
Abbate:
'68.
Liskov:
Yes. And I didn’t get any reasonable job offers. Of course, I didn’t really know to apply; but nobody was helping me.
Abbate: How did it work? Was there an old-boy network, and you would ask your advisor?
Liskov:
Yes. And I had an advisor who wasn’t particularly active, and I didn’t even really think to push on him. Maybe if I’d done that, then something would have happened. So I ended up with one faculty offer at Haywood State.
Abbate:
I don’t even know what state that’s in.
Liskov:
It’s in California. It’s a state college, and it had a heavy teaching load; and I had enough sense to say no to that. So I decided to come back to Boston, because at that time I was already in a relationship with my husband, and he was living in Boston.
Abbate:
Had you met him in Boston, previously?
Liskov:
No, I met him when I was a graduate student; he was out on business. I met him when he was out on business. And we’d already been together for almost two years by then. That was a big decision, though. I really waffled: “Should I go to Boston? Should I stay in California?” I went to Boston, and I actually came to MIT, and I looked for a job in the MULTICS project, but they would not give me a job. It was probably partly because I was coming out of AI, and that was a systems project—but who knows?
But I got a job at Mitre, and I actually got a job as a researcher; I started doing systems research. So it actually worked pretty well for me, because I made a switch of fields without having to also have the requirement of fast publication, and all the other stuff that goes along with being a faculty member. But I always thought I’d like to go back and become a faculty member. However, at that point, I was also still thinking in terms of, “I’m just going to work for a few years, and then I might stop and have a family.”
Abbate:
So: You’re at Mitre, you’re doing systems stuff . . .
Venus Research Paper
Liskov:
Yes. I had a nice research project, and as a result of this research project, I decided to write a paper. So I wrote this paper, and I submitted it to [a conference]. Oh, one thing that’s interesting: You’re going to talk to Judy Clapp on Sunday, right?
Abbate:
Yes.
Liskov:
She was my boss when I went back to Mitre. And that first paper that I wrote, I wrote it and I gave it to Judy. Now, nobody had ever —I mean, John McCarthy didn’t read and respond to my thesis [after] I submitted it—so I’d never got any feedback on technical writing. Judy was the only person who ever did that for me; but she really helped me write that paper, by reading it and criticizing it, so that I reorganized it and so forth.
So anyway, I submitted this paper to the top systems conference, and it got in. I gave my talk, and Jerry Saltzer, who was on the faculty here at MIT, was the chair of that session, and as a result I was asked to apply for a faculty position at MIT. I think that part of what was going on there was that Jerry Wiesner was the president, and he had decided that he needed to increase the number of women on the faculty—so it was sort of an active push.
Abbate:
I didn’t know that.
Liskov:
Yes.
Abbate:
Was that your first paper?
Liskov:
Yes. I might have written something, but it was certainly the first major paper. And it was a prize-winner in that conference; it was one of the top papers.
Abbate:
And that was an ACM conference?
Liskov:
Yes, this was SOSP [Symposium on Operating System Principles].
Abbate:
Right.
Liskov:
Right. This was the SOSP in 1971.
Abbate:
So you came to MIT in '71?
Liskov:
'72.
Abbate:
And you’ve been here ever since.
Liskov:
Yes.
Abbate:
What was that paper on?
Liskov:
It was on something called the Venus Operating System. What happened at Mitre was: I had this project where, first of all, I developed a machine architecture and implemented it using microcode, which was a big deal at that time. This machine architecture was interesting, because I put semaphores into it. This was at the time when Dijkstra had written his paper about the THE Operating System, and he proposed this notion of “semaphores,” which are still very basic in concurrent programming.
Abbate:
I’m not sure about semaphores.
Liskov:
Okay, well this is a way of providing mutual exclusion when you have multiple concurrent threads that need to access the same data. You need some mechanism that lets one thread in at a time, and then when it’s finished lets another one in. Semaphores were the mechanism that he proposed. They’re still very widely used; they may not be called that anymore. I put these in as a basic data type in the hardware, so the instructions to wait and signal were hardware instructions. The next stage of the research was to show that this was an interesting architecture, so I built this operating system on top of it. And what happened when I built the operating system was, I developed a modular design, which was the basis of all the work on data abstraction I did later. So, in trying to conceive how you would organize this big system modularly, I came up with all these ideas about narrow interfaces: that you don’t have just one entry point, and so you really think of a module as being something with a set of operations. This work was all done at about the same time that Dave Parnas was doing his work, and I wrote a paper on this that appeared in 1971, about the same time his work was appearing on pretty much the same ideas.
So it was the work on the Venus system which led me into this program methodology work, which then led to the data type work and programming language work. It was a sort of natural progression there. Then, at Mitre I was also doing some work—this paper that I had mentioned that was published on modular program construction, I also did that at Mitre. Because when the Venus project ended, I started working on program methodology, and they asked me to do a survey of all the work, and that’s what led me to think about what I’d been doing and develop these techniques. But if I’d stayed at Mitre, I don’t think I would have been able to take the subsequent steps, which were really branching out in a new direction.
Abbate:
It sounds like they did a fair amount of basic research at Mitre.
Liskov:
In those days they did. They must have been funded by the DoD—but I was protected from all that, so I don’t know where these contracts were coming from. Judy probably knows.
Abbate:
I hadn’t realized . . . I thought their stuff was all a bit more applied.
Liskov:
That’s another thing I couldn’t tell you, but my impression was that it changed shortly after I left, and maybe it was even changing when I was there. So they did do research, [but] it became more and more applied. I don’t know for sure.
MIT and Data Abstraction and CLU
Abbate: What do you think of as your main research achievements at MIT—the milestones, the things that you’re proudest of, or the most significant for you?
Liskov:
The first thing that happened when I came to MIT was, I started to think about these ideas about program methodology. I got the idea that it would be good to investigate these through a programming language, because on the one hand, this makes you be very precise about what the rules are—and otherwise you can be awfully mushy—and on the other hand, it’s a good medium for communication, because programmers think in terms of programming languages. So I invented the idea of abstract data types in that first few months when I was at MIT, and then I started working on the CLU programming language, and that work went on for about five or six years. I spent a lot of time working on the language design. It wasn’t just data abstraction in the programming languages, it was also a lot of work on what is a data abstraction, how do you specify it, and the distinction between the external specification and the internal details of the implementation. So there was a lot of work that I did in the ‘70s on data abstraction, programming languages, specifications: that was all part of that first project.
Also in that project we did a whole bunch of stuff that I didn’t really understand how revolutionary it was at the time. We invented an exception mechanism . . . .
Abbate:
Can you explain that?
Liskov:
When you make a call on a procedure, if it isn’t able to do its normal job, you would like it to be able to inform the caller in some way that both makes it hard to ignore the information, but also doesn’t clutter up the program with lots of tests. So the idea is that a procedure either returns normally, or it returns exceptionally with a named condition—and then you have to have some sort of mechanism in your language that makes it easy for you to catch those exceptions at a convenient point in your control flow. Java has exceptions.
It wasn’t that exceptions were totally new—I think even PL/I had some sort of brain-damaged exception mechanism; C++ has a truly brain-damaged exception mechanism. But this was early work; this was in the ‘70s; and we had a particularly nice clean one. I did some work then on different ways of handling exceptions, and so forth. Because there was a lot of discussion at that point about whether one should adopt the “termination” model, which is what I just described—the procedure stops and throws an exception—versus what they called the “resumption” model, which is where the procedure informs the caller of a problem, but then the caller is able to allow the procedure to continue running. I think PL/I has an exception mechanism like this. So I did a lot of work on assessing, and I came down on the side of termination, because resumption was so complex.
There were two other things developed in that language: there were iterators, which are a way of abstracting loop structures, and there was also parametric polymorphism, which is a way of writing a module that works over many types, rather than over a single type.
Abbate:
A single data type?
Liskov:
Yes. You see this in programming languages all the time: an array is a polymorphic structure, because you can have an array of integers, an array of reals, and so forth. What we had in CLU in the ‘70s was a mechanism where you could define an abstract data type of anything you wanted, and it would also have this same ability. So I could define a set, and when you would use it, you’d say, “Well, it’s a set of integers” or “It’s a set of reals.” And all the type-checking works properly, so you’d make sure that only integers are put in the set, and whatever’s coming out is an integer and has to go where an integer can go. So CLU was a strongly typed language.
Abbate:
The idea of “data abstraction” is that you have general data types that aren’t tied to specific . . .
Liskov:
They aren’t built into the programming language. You just invent them when you need them, based on whatever makes sense in the program that you’re writing. It might be application-specific: so in a banking system you have a bank account, with deposit and withdrawal operations. Or they might be related to storage management: so you’d have hash tables, and sets, and sequences, and all that sort of stuff. The idea was that you’d just define whatever made sense for you. You specify it, either formally or informally, describing what it means to use it. Then, when you implement it, you can implement it however you want—and the important point is that there’s an abstraction barrier, so that the using code isn’t able to actually have access to the details of the implementation. This means that if you need to reimplement it, you can do it without affecting the using code.
Traditional programming languages have this for procedures. You could use a procedure, and if someone decided to reimplement the procedure, that was okay: you could just call it; it didn’t affect the caller. There might be some performance implications, but there wasn’t some interleaved assumption on the side of the user about exactly the details of the implementation. But there wasn’t any similar idea for data. So that was the idea; data abstraction was to give you the same ability for data.
Abbate:
Whereas if you had something like C, and defined the type: it’s very concrete.
Liskov:
Oh, no, there’s no notion of abstraction. It’s very concrete.
The work that I did on CLU was happening at the same time as the work on Smalltalk, although the two groups were pretty much completely isolated and didn’t know much about each other. Smalltalk doesn’t really have data abstraction, or it didn’t in those days. It had the notion of a module, a class; you could define a data abstraction this way; but there was nothing in there that actually prevented the using code from accessing the details of the representation, so you didn’t really get the benefits. Actually, if you go back and read the literature on object-oriented programming, which I did in the ‘80s, what you discover is that they never thought about the distinction between the abstract behavior and the implementation. The papers are full of discussions about how the implementation works, and they take the implementation as being the definition of the meaning. It was really sort of an eye-opener to me, that that was going on.
Abbate:
I was going to ask you about that: the relation between your early work on data abstraction and current object-oriented work. Have you drawn on that?
Liskov:
I think the two have come together. If you look at modern object-oriented languages, like Java: the first thing you notice about Java is that it hasn’t got parametric polymorphism, which is a big pain in the neck and widely acknowledged to be a major weakness. But if you look at it from the point of view of methodology, what you see are very strong abstraction barriers, a clear understanding that there’s a distinction between the abstract data and the concrete data. So all those ideas that came out of work in data abstraction have sort of merged with work in object-oriented languages. I would say that the main accomplishment there was the type hierarchy—the idea that you can have a type that’s a subtype of another type—which definitely was not in any of the work I did on data abstraction.
In 1987 or so, I gave the keynote at OOPSLA, which is the big object-oriented programming language conference. That talk was about how they ought to be using abstraction principles to make sense out of hierarchy. So what I said in that talk was: When we define a subtype, it ought to have the same behavior as the supertype, as far as anybody using it could tell. A very simple idea, but nobody had said that before. This is known now as the Liskov Substitution Principle—it developed a life of its own! [laughs.] And that also is widely accepted as the way that you should use hierarchy. So I would say the two have come together quite nicely.
Abbate:
It sounds like they have.
By the way, what did CLU stand for?
Liskov:
Cluster. Cluster was the mechanism that you used to implement a data abstraction. The data abstraction is defined by its operations, and you need a linguistic mechanism that allows you to define the whole thing at once, so you thought of a data abstraction as being a cluster of operations. And so we used the word “cluster.”
Argus
Abbate:
All right, so you finished that around ‘79 . . .
Liskov:
Yes, and at that point, I jumped into distributed computing. I had a choice there: I could have continued working along the lines I’d been doing, and maybe even have pushed on trying to commercialize CLU. In a way I regret not doing that, but maybe it was hopeless anyway, because the way a language really becomes widely used is because some company like Sun puts a lot of weight behind it. Anyway, I decided not to do that; I decided to go off in a new research direction. So I jumped into distributed computing.
At that point, people knew how to build networks—this was early days of the ARPANET—but they had no idea how to write distributed programs. The question I was interested in was: How do you write a program whose structure is distributed, so it actually has components running on the various parts of the network? How did those components interoperate? So that led to a whole new research project that probably went on for about ten years, that developed a language called Argus. Argus is a strongly typed, object-oriented language, where the idea was that you would organize your program as objects that could interoperate—and you could place them at different places in the network.
Abbate:
“Argus” was a god with a thousand eyes or something?
Liskov:
Yes. The primary mechanism in Argus was something called a “guardian.” A guardian was a bunch of code that implemented a data abstraction and resided wherever you wanted to put it; and Argus was the guardian of the gods—so that’s where the name actually came from. The idea was that in a distributed program, what you’re doing is managing resources on behalf of other parts of the system, so the guardian was sort of a guardian of a resource. These are abstract resources.
Abbate:
Now, you’ve mentioned networking: Was this idea inspired by, or tied in with, the ARPANET work? Because I know the people there were talking about distributed computing. One of their aims—which was never really realized, as far as I can tell—was to have distributed computing all over the network, in parallel.
Liskov:
Oh yes: they wanted that; they just had no idea what it meant. So, this definitely was in the air at the time I started this project, it was just that nobody had any idea what it meant, so it was a big unknown. I found that appealing.
Another thing that happened: When I was designing CLU, I made an explicit decision not to put any concurrency into the language; because I felt that I had enough work on my hands, and if I added that too, we’d never make any progress. So another thing that happened when I switched over to Argus was, I took back up that concurrency stuff that I had put aside.
Abbate:
Concurrency is, you have two different programs running at the same time?
Liskov:
As many as you want.
Abbate:
Several programs; but you want to keep them in sync somehow?
Liskov:
They synchronize as needed. Distributed programs are naturally concurrent, because the typical thing that’s going on in a program like this is: You have users all over the place; they are interacting with the system—so each user is causing some activity—and this activity is happening in parallel with the activity on behalf of all the other users. That’s a particular kind of concurrency; and then there might be additional concurrency in the system: housekeeping jobs that you’re doing in the background, and stuff like that. It’s not the same flavor as another form of concurrent programming, which is what you see in big scientific computations—where the main focus there is, “I have a job to do; I can get it done faster if I do a whole bunch of things in parallel.” In distributed systems, that kind of concurrency has not been the main issue. The main issue has been simply the concurrency that comes from the fact that you’re trying to support simultaneous users.
Abbate:
A lot of different jobs at the same time, rather than one being run in parallel.
Liskov:
Yes, but nevertheless, they interact by sharing data. So one of the things that happened in Argus fairly early on was that I adopted transactions as the basic computation model. Transactions were an idea coming out of databases, where what’s nice about a transaction is that you’ll be running all sorts of transactions in parallel, and nevertheless the system will ensure that their execution is equivalent to having run them sequentially, in some order. It has rules controlling how they interact with data, that ensure that you will be able to say after the fact, “This one actually happened before that one”—even if they were running at the same time, and even if they were maybe even accessing the same data at the same time.
Liskov:
The other thing transactions give you is good behavior in the face of failures. So if there’s a failure in the middle of running a transaction and you’re not able to complete it, the mechanism guarantees that it’s as if it never ran at all. You don’t end up with it sort of half done.
And both of these are very important in distributed systems: the first one because there’s lots of concurrency, and the second one because, when you start to talk about computations that might span many different computers, you have to worry about the possibility that some of these computers might fail in the course of running the computations.
Abbate:
So the fault-tolerant aspect was an important part of it?
Liskov:
Yes.
[interruption]
Abbate:
You had an emphasis on fault tolerance in your system. Was that unusual?
Liskov:
It was ahead of its time.
There’s been a sort of consistency, though: I’ve always been interested in how you reason about programs, and how do you make sure your programs work as you want them to. And transactions are kind of a natural step in that direction, because they sort of straighten everything out: without them, things are a mess.
The argument I made at the time was: They’re very tricky to implement; it’s very easy to do them wrong; it’s actually complex. So you’d like to get it implemented once, and then at the level of where you’ve got your applications, you shouldn’t have to think about all those details. You can just reason at this higher level, where I can run all these things in parallel and the system will straighten it out for me.
Abbate:
Does that have applications for a client-server model of computing, in terms of: You’ve got things distributed around the Web. Is the idea of having these transactions between clients and servers based in any way on this model of transactions?
Liskov:
The problem with the transaction . . .
[interruption]
Abbate:
You were saying that the problem with transactions is: they’re expensive.
Liskov:
They are expensive. They require extra work to keep track of the interactions between the transactions. There are various way you implement them, and they either involve waiting or they involve aborting. So what happens in the Web is that most of the applications people are running [don’t use transactions for everything.] Think about your typical application: you’re doing online shopping. When you buy something, then you actually want to run a transaction, because if there’s some other person trying to buy something at that very moment, you’d like to make sure that if it’s the last item, one of you gets it and the other one finds out you can’t get it. In fact, they typically, at the back of these systems, have databases, and they do run transactions when you do these online modification activities; but as far as browsing is concerned, they aren’t very concerned about showing you a consistent state. So you might very well think you could buy something—because the information that you’re seeing is old—and then you’ll discover when you try to buy it that there’s a problem. So they use a kind of a hybrid: they use transactions for the modification part of it, but they don’t use transactions for the read part of it.
Abbate:
So “transactions” is kind of what the user intuitively thinks is going on, or hopes is going on—even if it’s not.
Liskov:
That’s right. And every now and then you’ll notice that you didn’t quite get it, because of the fact that the reads are not transactions. But, on the other hand, for something of the scale of the Web, and given how infrequently problems arise, it might be the right way to do it. On the other hand, if you were building a distributed bank, and you were doing bank transfers, then you would really use transactions for everything you did, because you want to make sure that you can say the system remained consistent.
It’s well known that are deficiencies with the model of computation being used on the Web right now. It’s okay for certain applications, not okay for others. And so I expect that the full transactional model will continue to be used for certain parts of what’s going on; and furthermore, distributed transactions are going to matter more and more, because there’s definitely a movement toward [distributed computing]—even individual data sites often run on many computers, and you need to have distributed transactions to make that part of it work. But as the end-user you may not see that, because you’ll continue with the simple browse-and-then-commit model that you are familiar with.
Abbate:
You’ve mentioned, for some of these projects you worked on, that people were doing similar work at other schools. How much interaction did you have with these? Were they just parallel projects without a lot of interaction?
Liskov:
Well, no. I didn’t have much interaction with the object-oriented work, but at the time that I did the CLU work, there was a similar project going on at CMU—Anita Jones and Bill Wulf—and we had a lot of interaction. In fact, there was a group of researchers that used to meet every six months or so, who were interested in program methodology. That was throughout the ‘70s, into the ‘80s, we used to meet. So there was a lot of interaction there. And then, when I moved into distributed computing, that was primarily systems work, and I’ve always been very tightly linked into the systems community.
So the object-oriented work was kind of an outlier. And that had as much to do with the fact that that was in industry, and they weren’t, you know . . . It wasn’t just me; nobody knew about that work. Bill and Anita didn’t know about it. It wasn’t considered relevant to what we were doing—it connected later, sort of like two different paths. But no: you always know about the similar work that’s going on at other places.
Abbate:
But not a lot of ties to industry.
Liskov:
Well, at that time industry wasn’t . . . There were a few industrial labs, and in general, yes, you always knew what was going on with the industrial labs; but there wasn’t research going on in industry. So yes, we knew what was going on in industry, because the only the interesting stuff was happening at the industrial labs.
Abbate:
That would be fairly small?
Liskov:
Yes.
Abbate:
Has that changed a lot?
Liskov:
Oh yes, it’s a different world today. Now the distinction between what happens in a startup and what happens in a research group is not that great. I mean, there’s more of a focus on getting a product out the door, versus maybe investigating more fundamental principles, but the problems you might be working on are similar. But that wasn’t true until maybe the ‘90s.
Abbate:
After you did Argus, what was next?
Liskov: So then, from Argus I got very interested in lots of distributed computing problems, and I started working on fault-tolerant mechanisms, replication algorithms. I wrote a paper on the use of synchronized clocks as a basis for distributed algorithms in general. Then I started working on Thor, which is an object-oriented database system. I got interested in the question of, “What’s a good model for persistent storage when you’re thinking about distributed applications?” And that was the project that I worked on in the ‘90s—so we’ve sort of surged through these decades! But all through the ‘80s and ‘90s I was doing lots of other work on distributed computing.
Abbate:
Were you involved with Project Athena [a distributed computing project at MIT]?
Liskov:
Not really. Project Athena was not a research project. Okay, I was involved in Athena in the following sense: In Argus, one of the problems that we had was, we needed a way to debug our programs. You had programs that consisted of these guardians running at many different places, and you wanted to be able to sit at a console and debug a program that had computation flow going through many different computers. Bob Scheifler, who was the inventor of X, worked for me, and he invented X in my project as a way of allowing us to debug distributed programs.
Abbate:
I had no idea. So the X Windows system came from your project.
Liskov:
It came from Bob Scheifler as part of the work he was doing here. And then what happened was, Jerry Saltzer, who was running Project Athena at the time, decided that a smart thing to do would be to bring X into Athena and develop it as a kind of industry-wide standard, without being owned by any particular company. Jim Gettys, who is the other person who is associated with X, started working on it at some point at this time, and Bob left my group so that he could run the X consortium.
Abbate: I was just curious, because theoretically at least, Athena was supposed to be a distributed system.
Liskov: It wasn’t a distributed system in the sense I’m talking about—it wasn’t intended to support distributed computation. It was a system that allowed students to work on their machines, access their files, communicate by email: so it’s a different thing. My project was interested in, “How would you write these programs?”
Abbate:
Okay. So Thor . . .
Liskov:
So then I worked on Thor. Thor’s an object-oriented database; it has strongly typed objects in the database, and you interacted by running transactions. It’s more on the database side of things, so I got kind of interested in database issues—but I never went way off. It’s along the same lines as stuff I’d been interested in since about 1980: transactions, and persistent storage, and replicating storage, fault tolerance.
Abbate:
Are you still working on that?
Liskov:
Not really. I mean, we’re using Thor as a basis for some other work. Right now one of the things I’m working on is software upgrades, so the question is: I have this huge database that’s got billions of objects in it, belonging to many different types—what happens if somebody decides they need to reimplement one of those types? And you’d like to cause all the objects of that type that are in the database to switch from where they are now to this new implementation. But you don’t want to stop the world, because it’s just too huge; so you want to do it incrementally, but you want to do it in a way that appears to have happened instantaneously. So that’s a current project that I’m working on, is how to make that happen.
Abbate:
That sounds like a miracle! [laughter.]
Liskov:
And the other thing that’s happened is: Through the students who were working on Thor, we got involved in follow-on work that wasn’t exactly Thor. Thor had a lot of interesting systems work in it having to do with “How do you manage your cache?” and stuff like that; it led to a lot of publications about very interesting techniques that we developed. Then some of my students started working on things that were sometimes fairly closely related to Thor, some of them a little bit farther out. Two things come to mind specifically, one of which I’m not really working on very much now, but the other one is still of interest to me. One of them had to do with privacy concerns. In today’s world, code moves around, or you might like to use somebody’s program to do something for you; but you want to be sure that if that program is manipulating private information, there’s no way it can expose it to the outside world. There actually are no very good techniques for doing this. So one of my students, Andrew Myers, developed a technique for information flow control, where the idea is that you use a type-checking–like mechanism to ensure that you keep track of owners of data, and then you can prevent data that’s owned by somebody from going out through a channel that isn’t authorized to carry that content. It’s a very nice, decentralized model. So that was one thing, and Andrew and I are still working on that, to some extent.
The other thing is Byzantine fault tolerance, which is replication techniques that allow a service to survive even malicious attacks. This is getting increasingly common on the Internet; you read about it in the paper all the time: Somebody hacks into Microsoft and destroys some data, or causes people to be sent off someplace else where they didn’t intend to go, or something like that. Traditional fault-tolerance has been based on the assumption that a computer fails by stopping, and that’s not what’s going on in these attacks. The computer is not working properly, but it hasn’t stopped; and so the question is, “How can you build a system consisting of replicas that, as a group, survive such attacks?” We have developed—this was work that I did with another student—a really good technique for building replicated systems that are able to survive attacks like this.
Abbate:
Now that, I would think, would be attractive to industry.
Liskov:
Well, it is and it isn’t. It’s expensive.
Abbate:
So they don’t want to pay for it.
Liskov:
Well, they might. I imagine what’ll happen is, this kind of system will be used in certain critical places, like the vault where you store the log of your credit transactions, or something like that—where you absolutely cannot stand a hacker attack causing loss of information.
Abbate:
How would you describe your interactions with students on research projects?
Liskov:
They vary from student to student.
Abbate: I don’t mean personally, but intellectually.
Liskov:
What you hope for in a relationship with a student is that you develop a peer. The good students are perfectly capable of doing this. I don’t know how you nurture that. I mean, I typically give my students a lot of room. For a master’s thesis, I typically will suggest a problem for them to work on, and help them find the right way. I try to let them solve problems themselves, but if they are having trouble, then I’ll jump in and do something. I think probably one important thing that an advisor has to do is to not solve problems for students. Sometimes it’s kind of tempting to do that, because you can do it so much faster than they can! [laughter.] Of course, by the time they get into their Ph.D., if they’re good, that isn’t true anymore. By then, they maybe can do it faster than you can—or at least you have somebody that you interact with as an equal, where you can really work together, and you don’t have to worry anymore that if you work on this problem, you’ll outshadow them. But when they’re young, or when they’re weaker, you have to hold back and give them room to work on the problem, and try to provide feedback, help them get over problems, but not sort of take over the project.
I don’t know . . . I feel . . . When my students leave, I mourn.
Abbate:
Do you notice any differences between male and female students, in terms of what they might need in the way of advising?
Liskov:
I don’t know how to answer that question. I haven’t had a huge number of female students. I’ve had a number over the years. They’ve always been pretty isolated in the group, because the majority of the students were male. It’s very hard to generalize about them. . . . I sometimes think that cross-sex relationships might be easier. Some of my [male] colleagues have a lot of women students, and they seem to be able to nurture women students in a way that I haven’t seemed to be able to do—and I don’t understand what the basis of that is.
Abbate:
Do you think it’s partly area choice; that women gravitate to certain areas of computer science? Have you noticed any patterns?
Liskov:
I don’t think there are very many women in systems. So if I compare my group to other groups, I’m probably no different than they are, in my area. So yes, I think it is. And there probably are more women in AI at this point.
Abbate:
Do you have any idea why that is?
Liskov:
Touchy-feely? AI is a little more touchy-feely? But I don’t know. It’s a mystery to me: I don’t understand why the population of women in computer science hasn’t been going up. I think we’re dealing with very deep-seated societal problems here, having to do with how women are socialized and nurtured. These are problems that don’t kick in at the university level—they’re there already.
Abbate:
Yes, this is almost the end of the pipeline, by the time they get here.
Liskov:
I don’t know, for example, what the statistics are exactly; but my impression is that at the undergraduate major level, we are running at about 25 percent women.
Abbate:
At MIT, you mean?
Liskov:
At MIT, in my department—although MIT as a whole is running more like 40 percent women, so there’s definitely a gap there, which we don’t understand. The department doesn’t understand this. We don’t know what is causing it. And then there’s a further jump from undergraduate to graduate school. I think at the graduate level we only have about 15 percent. I don’t understand that either.
Now, this is very peculiar time in computer science, because it’s such a good time to go out in industry. Maybe a little less true now than it was a year ago, but . . . Fields don’t have periods like this very often—when startups can make billions—and it’s very exciting. So the whole business of students going to graduate school is a little bit weird right now; it’ll probably settle down in a few years. And it may be that women right now are more in demand than men in industry—because all the companies are trying to solve their own set of problems. But I don’t understand it.
Abbate:
So you don’t know if it’s a “push” out of academia or a “pull” into industry, in terms of going to graduate school.
Liskov:
We have no idea. I just finished a student with the master’s degree—a very bright, capable woman, who is going to work in industry. But she told me when she left that she thought she’d probably go back to graduate school in a year or so—which I was really glad to hear, because she’s clearly capable. But you know, some of them leave and they don’t come back.
Abbate:
Have you encountered any overt discrimination, in terms of experiences at conferences, or with colleagues, or . . . ?
Liskov: My situation is not the usual one. The first conference I ever went to, I had a prize-winning paper, and after that, I was already known. After that, I started going to conferences having to do with data abstraction—but I invented the idea, you know. So I never went there as the student whom nobody knew, who could be ignored. So I probably have not had normal experiences; I’ve always been known at the conferences that I go to.
It’s hard for me to see it. I’ve wondered, when I talk to other women and they explain these problems that they’ve had . . . I feel in my department that I’ve always felt welcomed, and they’ve certainly put me on important committees, listened to what I had to say. So I feel that it’s been fine. But it could be that, because I have this way of being sort of oblivious to things, that I haven’t noticed things.
Abbate:
Well, I think people have very different experiences . . .
Liskov:
Yes.
Abbate:
I’m not suggesting that it had to happen; I was just asking.
Liskov:
Right.
Abbate:
Sometimes being oblivious can be a good thing, though!
Liskov:
Well, you know, I do think it protects me from things where other women might feel slighted. I just sort of don’t notice.
Family
Abbate:
How have you balanced work and family commitments?
Liskov:
I always took the position that you should only work 40 hours a week—and I pretty much did that, all those years.
Abbate:
You didn’t feel pressure that if you wanted to get tenure, you had to be a workaholic, or anything like that?
Liskov:
No, I felt that if I didn’t get tenure, it wasn’t the end of the world. There were lots of other opportunities out there. At least, this is what I told myself. I must say, when I got tenure, I did feel less pressure—but I never responded to that pressure by trying to work more hours, because I didn’t feel that that was productive. I feel that the most productive way to work is, you work in a concentrated period, and put it down—and then, an awful lot of work happens sort of unconsciously, when you’re processing it; so that by the time you come back the next day, you’ve already had a new idea or something like that. And that’s really how I’ve always worked.
Abbate:
Well, it certainly worked for you!
Liskov:
It certainly worked for me. It doesn’t work for everybody.
I have one child, who is now 25. I had him late—I was 36 when he was born—and we got a full-time baby-sitter, so that helped. And my husband was able to—when we had a crisis, we were always able to work something out. An academic position is good, actually, for having children, because there are so few time constraints. You have to teach your course, but aside from that, anything else can be rescheduled. So it makes it pretty easy to work around most of the problems that you encounter. Nevertheless, it’s really a race. Do you have children yourself?
Abbate:
No.
Liskov:
It’s a real rat race, and you’re always worrying about what happens if the baby-sitter can’t come, what happens if the after-school program is canceled—you know, it’s just a constant battle.
Abbate:
What does your husband do?
Liskov:
He is an electrical engineer. He worked for Raytheon. He’s actually retired now, but he worked for Raytheon. So he didn’t have as much flexibility as I did, but still, he was a very high level designer-architect, so he could always work at home most of the time. So that helped, too. He was both flexible and also very supportive.
Abbate:
Did you talk to him about your work? Did you have some common ground . . .?
Liskov:
No. He knows just enough about computer science to be aggravating! [laughter.] You know, he doesn’t know very much, so no: we never really talked about work.
Abbate:
That could be a good thing.
Liskov:
Yes. I think I’m pretty competitive, and if we’d been closer together, it might have been difficult. So it’s probably just as well.
Abbate:
What have your teaching experiences been like?
Liskov:
Fine.
Abbate:
I don’t know if you do a lot teaching—undergraduate, graduate . . .?
Liskov:
At MIT you teach one course a semester. I’ve done primarily undergraduate teaching, and that’s because I developed a course based on my programming methodology work, which led to this book here. [gets book off shelf]
Abbate:
[reading title] Program Development in Java.
Liskov:
Yes. Well, I wrote an earlier book; I developed this course in the early ‘80s, and there was a first version of this book, and I taught the course in CLU for many years. Then I switched over in the ‘90s—finally, when Java came along, I switched to Java. I actually tried to teach it in C++ for a couple of years. Anyway, I taught this course many times. Of course, when you’re working on a book, you want to be teaching the course, because you are sort of refining the ideas.
So I haven’t done graduate teaching for a long time, and I haven’t even taught other courses for a long time. And I’ve actually been on sabbatical, now; I went on sabbatical last January. I joined a startup, and my startup was then bought by Cisco, so I’ve been working for Cisco; and I decided to take a leave. So I’m only at MIT on Thursdays, and I won’t be back until the fall, and exactly what’ll happen then, I don’t know.
Abbate:
What is the startup doing?
Liskov:
Well, it’s not a startup anymore! This particular part of Cisco—you know, now we’re part of Cisco—we build what are called content-delivery networks. These are distributed systems that take Web content and distribute it across the Internet; and then when users want to access that content, we have a way of routing them to the appropriate nearby server that contains the content that they’re interested in.
Abbate:
Do you find it different working as part of a company than being an academic?
Liskov:
Oh, yes; it’s very different. I do architecture there—so I design systems; I design algorithms. I’m having a lot of fun doing this. It’s not the same as doing research. I’m still actually doing research, because I have my students . . .
What time is it, by the way?
Abbate:
It’s about 11:35.
Liskov:
Oh . . . .
[interruption]
Abbate:
You were saying something about Cisco and working on the architecture . . . .
Liskov:
Yes. I do a lot of design, and algorithm development, and it’s fun; I’m having a good time. And I got very invested in this product that I was working on, and that’s why I decided to stay on a little bit longer. It was at Phase 1, and now we’re working on Phase 2, and then there’s a Phase 3 sort of looming, and hopefully that’ll be well on its way by the time I come back in the fall.
Abbate:
Is this an actual product on the market, or is it still under development?
Liskov:
Oh yes. So that’s a very different experience.
Abbate:
Is this the first thing that’s really been directly been turned into a product that you’ve worked on?
Liskov:
Yes—well, I mean, this is not stuff I brought from MIT to this company. So yes, this was the first time I’ve ever worked on something that turned into a product. So it is a different experience, and it’s also interesting from the point of view of 6170—the course that this is the book for—to see what kinds of programming practices are used in industry.
Abbate:
What would you say are the most satisfying aspects of working in computer science, for you?
Liskov:
First of all, I think that I am a person who values—who enjoys—doing research more than teaching, and I’ve had some very interesting research projects. It’s been very creative, and I’ve been inventing things—and that’s very exciting when that happens. The years I was working on CLU, there were several years there where it was just constant invention. This has happened to me many times; sometimes it’s solving a big problem, sometimes it’s a smaller problem, but I really enjoy that creative process. I would enjoy that in any field; computer science happens to be, maybe, the field that’s the right one for me, because it matches my abilities so well. And I like interacting with the students; that’s very rewarding.
Abbate:
Do you have any advice for young women who might be thinking about entering computer science?
Liskov:
The advice I give people in general is that you should figure out what you like to do, and what you can do well—and the two are not all that dissimilar, because you don’t typically like doing something if you don’t do it well. It’s good not to have any real preconceived notions of what this is going to be, because you don’t necessarily know yourself that well when you’re starting out. So you should instead watch—be aware of what you’re doing, and what the opportunities are, and step into what seems right, and see where it takes you.
Abbate:
Sound like great advice.
All right. I’ll probably just wrap it up here.
Liskov:
Okay.
Abbate:
Thanks so much!
Liskov:
You’re welcome.
Abbate:
It’s been really interesting.
