Interview It has been 12 years since Barbara Liskov won a Turing Award for her contributions to practical and theoretical foundations of programming language and system design, and these days the creator of the CLU programming language continues to work on some interesting problems.
We spoke about innovation, abstraction and encapsulation in the 1970s and today in a recent chat.
Liskov, now in her 80s, leads the Programming Methodology Group at the Massachusetts Institute of Technology. Recently, she has been working on parallel computing and, with a student, developed Byzantine Fault Tolerance* [PDF] in the 1990s, "which turns out to be very significant for the blockchain world," she says.
However, with the arrival of CLU on GitHub, focus has turned to Liskov's earlier work, with her students, in the creation of the language in the early 1970s.
I think that programming and software engineering is still an exciting career
"One of the the interesting things about CLU," she says, "was that due to the state of programming languages at the time, there was a lot of stuff to innovate in order to get CLU off the ground.
"For example, we had to face up to the issue of generics. Before there was a notion of abstract data types you actually already needed generics. If you wrote a sort routine, you didn't want to keep rewriting it every time you had a different kind of array. But people hadn't really faced up to that yet.
"And as soon as you have abstract data types, it becomes absolutely clear that you need generics," she says. "So we had to figure out what to do about generics, and that was a big deal."
And then there was exception handling, which tended to be a bit primitive back in the day. Liskov recalls the debate over what was referred to as the resumption model versus alternatives: "The question was, after the exception was raised, did control then revert to the code that had raised the exception, or did it just end that code? And so we had to face up to that."
- Give us a CLU: Object Oriented Programming pioneer arrives on GitHub
- Up with cohesion, down with coupling
- Google fiddles with cross-platform Flutter and Dart to boost performance, tooling
- There's more to blockchain than dodgy cryptocurrencies
- An unthinking programmer's guide to the new C++
"If you don't have a way of dealing with the error cases separately from the main flow, then, what happens still today unfortunately, is that there are a lot of errors in code that often show up far from the source of the error. So the harder it is to track down."
Liskov continues: "We had to do a lot of innovation because we were working on stuff that people hadn't faced up to yet.
"Data abstraction is a big deal," she says, "but all this other stuff comes along with it."
"If you look back at, for example, what happened to Java in the '90s with the way they did parametric polymorphism, which was they didn't," Liskov laughs, "you can see also with exception handling, people really have never quite got their act together."
What happened to Java in the '90s with the way they did parametric polymorphism.... was they didn't. You can see also with exception handling, people really have never quite got their act together
Of course Liskov and her co-creators had the luxury of CLU being a research project and so not subject to the demands of multiple groups. However, by the late 1970s a fork in the road was reached: try to make a commercial go of the language, or stick with research. Liskov opted for research. "None of the students in my group," she says, "felt like doing a startup."
Noting the difference with the experience of today, where throwing something up online and building a community around it is a relatively simple process, she says that things were quite different as the 1970s drew to a close. "You had to go through a company," she explains. "If I'd had a couple of students who felt like doing that… but even then it was hard to get startup money. It was a real different time than it was by the time the early '90s came around."
Then again, the nature of CLU is that it did not collect the cruft that has afflicted so many other languages over the years. "Whenever a language gets started," Liskov says, "it starts to develop its legacy. And then you have this problem that you have to continue to support all the code that was written and it creates baggage."
Most of the development work in the last 20 years in which Liskov has been involved has been in C++. "Program development is not done using machine language anymore. And that's a big improvement," she says, "just getting up that level of abstraction. And I do think that the principles of modularity are pretty well understood."
However, "One of the things I deplore or I wish were different is I wish that languages enforced encapsulation."
"It is true," she concedes, "that sometimes you have to violate encapsulation. And that's typically when you're building some low level platform."
However, Liskov contends that encapsulation - the bundling of data, along with the methods that work on the data, into a single unit that restricts access to data internals to just those methods - is a key piece of programming methodology: "the one that makes modularity work."
"The best thing you can do academically is to add it on and talk to the students about how important it is. But that's not the same thing as having a compiler enforce it."
Still, other things have improved. The cavernous storage capabilities of today (at least compared to what was available in the 1970s) mean compactness can take a back seat to elegance when designing modules: "Yes, you want it to be usable on the one hand, but as simple as possible on the other."
Liskov is keen to give credit to her students Russ Atkinson, Alan Snyder and Craig Schaffert as well as Stephen Zilles, who was also at MIT and worked with her in 1973 refining the concepts that underlay CLU.
Liskov – who is also responsible for the Liskov Substitution principle** – continues to be enthusiastic about programming and technology, and tells us: "I think that programming and software engineering is still an exciting career.
"I think the distinction between the interface and the implementation is really good to keep in mind, you know… getting the behaviour to be defined separate from the implementation.
"And if you aren't in a language which enforces encapsulation, which is unfortunately most of them, then you have to impose that on yourself." ®
*One of the consensus mechanisms that helps maintain the integrity of the blockchain system
**Broadly, that "objects of a superclass shall be replaceable with objects of its subclasses without breaking the application"