Turing Award winner Barbara Liskov on CLU and why programming is still cool

Interview It has been 13 years since Barbara Liskov, won a Turing award for her contributions to the practical and theoretical foundations of programming language and systems design, and these days the creator of the CLU The programming language continues to work on some interesting problems.

We talked about innovation, abstraction and encapsulation in the 1970s and today in a recent talk.

Liskov, now in his 80s, leads the Programming Methodology Group at the Massachusetts Institute of Technology. Recently, you have been working on parallel computing and, with a student, made up Byzantine fault tolerance * [PDF] back in the 1990s, “which turns out to be very important to the blockchain world,” he says.

However, with the arrival of CLU on GitHub, attention has focused on Liskov’s earlier work, with his students, on the creation of language in the early 1970s.

I believe that programming and software engineering continue to be an exciting career.

“One of the cool things about CLU,” he says, “was that due to the state of programming languages ​​at the time, there were a lot of things to innovate for CLU to take off.

“For example, we had to deal with the problem of generics, because before there was a notion of abstract data types, generics were already needed. If you wrote a sort routine, you didn’t want to keep rewriting it every time you had a different type of data. matrix, but people still hadn’t faced that.

“And as soon as you have abstract data types, it becomes absolutely clear that you need generics,” he says. “So we had to figure out what to do with generics, and that was a big problem.”

And then there was exception handling, which used to be a bit primitive in the past. Liskov recalls the debate on what was called the resumption model versus alternatives: “The question was, after the exception was raised, did control revert to the code that generated the exception or did it just end up with that code? that “.

“If you don’t have a way to deal with the error cases separately from the main stream, what is still the case today, unfortunately, is that there are many errors in the code that often appear far from the source of the error. difficult to locate “.

In addition to error handling, more innovations in iterators were introduced. “One of the things it meant was that we were a little ahead of the time,” Liskov continues, “because we were working on things that people hadn’t yet dealt with.”

“Data abstraction is a big problem,” he says, “but all these other things come with it.”

“If you look back, for example, what happened to Java in the 90s with the way they did parametric polymorphism, which they didn’t,” laughs Liskov, “you can also see with exception handling, the people have never really gotten to act together. “

What happened to Java in the 90s with the way they did parametric polymorphism … was that they didn’t. You can also see that with exception handling, people have never been quite right.

Of course, Liskov and his co-creators had the luxury of CLU being a research project and therefore not subject to the demands of multiple groups. However, a fork in the road was reached in the late 1970s: attempting to make a commercial turn of the language or pursuing research. Liskov opted for research. “None of the students in my group,” he says, “felt like starting a company.”

Noticing the difference to today’s experience, where launching something online and building a community around it is a relatively simpler process, he says things were quite different when the 1970s came to a close. “You had to go through a company,” he explains. “If I had a couple of students who wanted to do that … but even then it was hard to get the money to start. It was a really different time than the early nineties.”

On the other hand, the nature of CLU is that it did not pick up the cruft that has affected so many other languages ​​over the years. “Whenever you start a language,” says Liskov, “it begins to develop its legacy. And then the problem arises that you have to keep supporting all the code that was written and it creates a baggage.”

Most of the development work in the last 20 years that Liskov has been involved in has been in C ++. “A lot of development is not done in machine language programming anymore. And that’s a huge improvement,” he says, “just to raise that level of abstraction. And I think the principles of modularity are pretty well understood.”

However, “One of the things that I deplore or wish they were different is that I would like languages ​​to enforce encapsulation.”

“It’s true,” he admits, “that sometimes you have to violate encapsulation. And that’s typically when you’re building a low-level platform.”

However, Liskov argues that encapsulation – the grouping of data, along with the methods that work with that data, into a single unit – is a key piece of programming methodology: “the one that makes modularity work”.

“The best thing you can do academically is add it and talk to students about how important it is. But that’s not the same as having a compiler to enforce it.”

Still, other things have improved. Today’s cavernous storage capacities (at least compared to what was available in the 1970s) mean that compactness can take a backseat to elegance when designing modules: “Yes, if you want it to be usable by one side, but as simple as possible on the other. “

Liskov is willing to credit 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 underlying CLU.

Bob Scheifler, Eliot Moss and Toby Bloom also appear in the CLU Reference Manual October 1979 (PDF). Paper, CLU history [PDF], gives a more detailed list of credits.

Liskov – who is also responsible for the Liskov substitution principle ** – remains excited about programming and technology, telling us, “I think programming and software engineering continues to be an exciting career.

“I think it’s very good to take into account the distinction between interface and implementation, you know … to have the behavior defined separately from the implementation.

“And if you are not in a language that enforces encapsulation, which unfortunately most of them are, then you have to impose it on yourself.” ®

* One of the consensus mechanisms that helps maintain the integrity of the blockchain system.

** In general terms, that “the objects of a superclass will be replaceable by objects of its subclasses without interrupting the application”.

Leave a Comment