Communications - July 2009

last byte

DOI: 10.1145/1538788.1538815
Q&A
Liskov on Liskov

Barbara Liskov talks about her groundbreaking work in data abstraction and distributed computing.

BarBara liskoV, a
professor at the Mas-

sachusetts Institute of Technology (MIT) and winner of the 2008 ACM A.M. Turing Award, has worked throughout her career to make software systems more accessible, reliable, and secure. We caught up with her recently to discuss a few of her most important accomplishments—and to find out what she’s working on now.

Let’s talk about CLu, the programming language you developed in the 1970s to handle abstract data types. Before I came to MIT, I was working on the VENUS system, and I got some ideas about a different way of modularizing programs around what I called multi-operation modules. When I came to MIT, I started to think of that in terms of data types. And then I decided the best way to continue the research was to develop a programming language.

how did your ideas differ from the research that was going on at the time? When I started, the main way people thought about modularization was in terms of subroutines—of abstracting from how you wrote a procedure to calling that procedure, say, a sort routine, or a lookup routine. But they didn’t have any way of linking a bunch of procedures together.

And that’s what CLu’s clusters accomplish. Yes. A cluster would have all the operations you needed to interact with a data object, and inside you could

implement it and later re-implement it however you wanted.

eventually, object-oriented programming evolved from your work on CLu. Object-oriented programming evolved from two different strands. There was my work on data abstraction and some

Leah Hoffmann

related work that was going on at [Carn-egie Mellon University]. The other influence was Smalltalk. Both of these were sort of getting at the same idea in slightly different ways, but the big difference between my work and the Smalltalk work was that I focused on making a very strong distinction between what a module did [Continued on p. 119]