Maintenance It’s been 13 years since Barbara Liskov won a Turing Award for her contributions to the practical and theoretical foundations of the programming language and systems design, and these days the creator of the CLU programming language continues to work on issues. interesting.
We talked about innovation, abstraction and encapsulation in the 1970s and today in a recent chat.
Liskov, now 80, heads the Programming Methodology group at the Massachusetts Institute of Technology. Recently she worked on parallel computing and, together with a student, invented Byzantine fault tolerance * [PDF] in the 1990s, “which is very important to the blockchain world,” she says.
However, with CLU’s arrival on GitHub, attention turned to Liskov’s earlier work, with his students, in language creation in the early 1970s.
I think programming and software engineering is always an exciting career
“One of the interesting things about CLU,” she says, “was that due to the state of programming languages at the time, there was a lot of innovation to get CLU off the ground.
“For example, we had to deal with the issue of generics, because before there was any notion of abstract data types, you actually already needed generics. If you were writing a sorting routine, you didn’t want to rewrite it every time you had a different kind of array, but people hadn’t really coped with 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 the generics, and that was a big deal.”
And then there was the exception handling, which tended to be a bit primitive at the time. Liskov recalls the debate over what was called the recovery model versus alternatives: “The question was, after the exception was thrown, did control revert to the code that triggered the exception, or did he just terminate this code? And so we had to face it. “
“If you don’t have a way to handle error cases separately from the main stream, then unfortunately what still happens today is that there are a lot of errors in the code that appear. often far from the source of the error. So the harder it is to find. “
In addition to error handling, other innovations in iterators were presented. “One of the things that meant was that we were sort of ahead of time,” Liskov continues, “because we were working on things that people hadn’t really faced yet.”
“Data abstraction is a big deal,” she says, “but all of these other things come with it. “
“If you look at, for example, what happened to Java in the 90s with the way they did parametric polymorphism, which it didn’t,” Liskov laughs, “you can also see with the management exceptions, people really never quite their act together. “
What happened to Java in the 90s with the way they did parametric polymorphism … is that they didn’t. You can also see that with exception handling, people never really got along
Of course, Liskov and his co-creators had the luxury that CLU was a research project and therefore not subject to the demands of several groups. However, in the late 1970s a crossroads was reached: try marketing the language or stick to research. Liskov opted for research. “None of the students in my group,” she said, “wanted to do a startup.”
Noting the difference with today’s experience, where launching something online and building a community around it is a relatively simpler process, she says things were quite different in the late 1970s. had to go through a company, she explains. “If I had had a few students who wanted to do this… but even then it was hard to get start-up money. It was a very different time than the early 90s.”
Then again, the nature of the CLU is that it hasn’t collected the grime that has plagued so many other languages over the years. “Every time a language starts up,” Liskov says, “it starts to develop its heritage. And then you have this problem that you have to keep taking over all the code that has been written and that creates baggage.”
Most of the development work over the past 20 years that Liskov has been involved in has been in C ++. “There’s not a lot of development in machine language programming anymore. And that’s a big improvement, ”she says,“ you just need to raise that level of abstraction. And I think the principles of modularity are fairly well understood. “
However, “One of the things that I regret or wish were different is that I wish languages would force encapsulation.”
“It’s true,” she concedes, “that sometimes you have to violate the encapsulation. And that’s usually when you’re building a low-level rig.”
However, Liskov argues that encapsulation – the grouping of data, along with the methods that work on that data, into a single unit – is a key part of the programming methodology: “the one that makes modularity work.”
“The best thing you can do academically is add it and tell students about its importance. But that’s not the same as asking a compiler to apply 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 give way to elegance when designing modules: “Yes, if you will. that it be usable on the one hand, but as simple as possible on the other. “
Liskov would like to thank 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 to refine the concepts behind CLU.
Bob Scheifler, Eliot Moss, and Toby Bloom are also listed in the October 1979 CLU Reference Manual (PDF). Paper, History of CLU [PDF], gives a more detailed list of credits.
Liskov – who is also responsible for the Liskov Substitution Principle ** – continues to be passionate about programming and technology, and tells us, “I think programming and software engineering is still an exciting career.
“I think the distinction between interface and implementation is really good to keep in mind, you know… getting behavior defined separately from the implementation.
“And if you’re not in a language that enforces encapsulation, which unfortunately is most of them, then you have to enforce it on yourself.” ®
* One of the consensus mechanisms that helps maintain the integrity of the blockchain system
** Basically, that “objects from a superclass must be replaceable by objects from its subclasses without breaking the application”