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

Error handling and encapsulation remain the name of the game


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."

"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.

Bob Scheifler, Eliot Moss and Toby Bloom also appear on the CLU Reference Manual of October 1979 (PDF). The 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 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"

Similar topics


Other stories you might like

  • Research finds consumer-grade IoT devices showing up... on corporate networks

    Considering the slack security of such kit, it's a perfect storm

    Increasing numbers of "non-business" Internet of Things devices are showing up inside corporate networks, Palo Alto Networks has warned, saying that smart lightbulbs and internet-connected pet feeders may not feature in organisations' threat models.

    According to Greg Day, VP and CSO EMEA of the US-based enterprise networking firm: "When you consider that the security controls in consumer IoT devices are minimal, so as not to increase the price, the lack of visibility coupled with increased remote working could lead to serious cybersecurity incidents."

    The company surveyed 1,900 IT decision-makers across 18 countries including the UK, US, Germany, the Netherlands and Australia, finding that just over three quarters (78 per cent) of them reported an increase in non-business IoT devices connected to their org's networks.

    Continue reading
  • Huawei appears to have quenched its thirst for power in favour of more efficient 5G

    Never mind the performance, man, think of the planet

    MBB Forum 2021 The "G" in 5G stands for Green, if the hours of keynotes at the Mobile Broadband Forum in Dubai are to be believed.

    Run by Huawei, the forum was a mixture of in-person event and talking heads over occasionally grainy video and kicked off with an admission by Ken Hu, rotating chairman of the Shenzhen-based electronics giant, that the adoption of 5G – with its promise of faster speeds, higher bandwidth and lower latency – was still quite low for some applications.

    Despite the dream five years ago, that the tech would link up everything, "we have not connected all things," Hu said.

    Continue reading
  • What is self-learning AI and how does it tackle ransomware?

    Darktrace: Why you need defence that operates at machine speed

    Sponsored There used to be two certainties in life - death and taxes - but thanks to online crooks around the world, there's a third: ransomware. This attack mechanism continues to gain traction because of its phenomenal success. Despite admonishments from governments, victims continue to pay up using low-friction cryptocurrency channels, emboldening criminal groups even further.

    Darktrace, the AI-powered security company that went public this spring, aims to stop the spread of ransomware by preventing its customers from becoming victims at all. To do that, they need a defence mechanism that operates at machine speed, explains its director of threat hunting Max Heinemeyer.

    According to Darktrace's 2021 Ransomware Threat Report [PDF], ransomware attacks are on the rise. It warns that businesses will experience these attacks every 11 seconds in 2021, up from 40 seconds in 2016.

    Continue reading

Biting the hand that feeds IT © 1998–2021