You are here: silicon.com > Management > IT Pro

IT Pro

'If Google decided to misbehave there'd be big trouble'

Q&A: Turing Award winner on the cloud, women in IT and the dangers of data mining

Tags: software engineering, computing, turing, barbara liskov

By Natasha Lomas

Published: 8 April 2009 13:28 GMT

2008 Turing Award winner Barbara Liskov speaks to silicon.com about her research and hot issues from security to gender gaps.

The winner of the 2008 ACM AM Turing Award for lasting and major technical contributions to the computing community was announced last month as Barbara Liskov, a professor at the Massachusetts Institute of Technology (MIT).

The Turing Award, which is named after British mathematician Alan Turing, has been awarded by the Association for Computing Machinery every year since 1966. Past winners include Vint Cerf, commonly called 'father of the internet' and Google's internet evangelist.

Liskov, who heads up the Programming Methodology Group in the Computer Science and Artificial Intelligence Laboratory at MIT - where she has conducted research and has been a professor since 1972 - is only the second woman to receive the prize. IBM's Fran Allen won the 2006 award.

silicon.com recently spoke to Liskov about her work and current research interests, and heard her views on a variety of IT issues - from data breaches and cloud computing to the relative lack of women in the IT industry.

silicon.com: Can you explain the significance of the work that won you the Turing prize. What impact has it had on computing?
Barbara Liskov I won the prize for my work in developing techniques that... make it easier to build big software systems. The problem in software is there are no obvious boundaries to contend with. For example if you build some kind of electrical device you do that with discrete components - wires and boxes - and this naturally leads you to think about a design in which you go for pieces that may have very complicated insides but on the outside they have some sort of simple interface.

A good example here is a clock where there's a kind of standard interface but on the inside there may be a very complicated way to implement it. As far as the user's concerned, all you have to think about is, 'what is that interface about?' and 'what do I get to do with it?' You don't have to worry about the implementation details and you can use one clock or another clock and there really isn't - as far as you're concerned - any difference between them.

In software though there were no obvious boundaries like that - and the work that I did was to develop a way of putting complicated software systems into modules where each module presented to its users a relatively simple interface and then on the inside there could be a complicated implementation; the user didn't have to worry about that. And furthermore if that implementation changed then the user was unaffected by that change.

Everything you do on the internet can be collected and people can mine that information so there's another kind of breach of confidentiality... there's immense problems lurking - coming up in the future.

So this is the idea of abstract data types or data abstraction. What inspired it was some early work I did in building a system where along the way I began to think about, 'how am I ordering this system and what is a good way to do it?' Prior to my work the only way that people modularised software was in terms of what were called subroutines so you could think about, 'I want a procedure that's going to sort a bunch of items into some increasing order'. You could use the sort procedure to accomplish that and you didn't have to worry about the algorithm that was used inside.

What I did was to extend the idea to abstract from details of how data were represented. That gave us a much more powerful abstraction mechanism where the modules could be much bigger and a lot more information could be hidden.

I then developed a programming language that included this idea. I did that for two reasons: one was to make sure that I had defined everything precisely because a programming language eventually turns into code that runs on a machine so it has to be very well defined; and then additionally because programmers write programs in programming languages and so I thought it would be a good vehicle for communicating the idea so they would really understand it.

That programming language, which was called CLU, never made it out beyond academic circles. It was definitely an implemented language. We used it at MIT and it was used at a number of other academic institutions but it didn't make it into commercial use. What happened instead was that the ideas in CLU moved into mainstream languages because they were accepted by the community as being important ideas. So they moved into Ada which was a language that was developed by the Department of Defense. They moved into C++. Later they moved in Java and now into C sharp.

[My ideas] are now widely accepted and all programs are built using these techniques.

What inspired you to get into computing?
I got in sort of by accident. When I graduated from college I had a degree in math and I decided I wasn't interested in going to graduate school right away. So I decided to get a job and I couldn't find an interesting job as a mathematician - I was able to get a job where essentially they wanted me to plot graphs - but I got an interesting job as a programmer. Then I discovered that I had a real bent for computation and so that's what got me into the field.

How does one write good software? Are there a basic set of principles software engineers should follow?
It's not easy to write good software… It's not difficult to write tiny programs but when you try to write a big piece of software and, after all, in our everyday life nowadays we deal with very large pieces of software. For example Google - behind the scenes, immense quantities of software [make] that system run.

There are really two parts to it - one of them is understanding the basic techniques that you can use, so this idea of data abstraction and modularity is very important. The other part of it is more like a craft. Because you have to think about what's the right way - even when you have the right idea of what the building blocks should be still there's huge flexibility in how you decide to put the whole system together.

It's a craft and some people can learn it, and it has a lot to do with valuing simplicity over complexity. Many people do have a tendency to make things more complicated than they need to be.

There's another problem that people in the real world have to cope with…

For more from Barbara Liskov click here for page two

  1. Zones
  2. Management
  3. Networks
  4. Software
  5. IT Services
  6. Hardware
  1. Verticals
  2. Public Sector
  3. Financial Services
  4. Retail & Leisure

Naked CIO Naked CIO: Social networks are useless for finding a job 'Quantity over quality' approach poisoning professional networks

Peter Cochrane Peter Cochrane's Blog: Uneconomics We must move away from short-termism to prevent next economic crisis


  • Jobs
IT and Laser Room Manager - Direct Mail

They require an IT Manager to be able to run a small laser department were they can use their knowledge of Data Merging, De-dupe, Mail Sort and Laser ...

Parallel Processing/Multi-Core – Embedded Software Engineer

Qualifications are seen as proof of ability – they require a 1st or 2.1 in Computer Science, Engineering, Science or Maths, from one of the ...

SQL Server Developer - Bristol - 23K-27K

You will be responsible for Developing reports and stored procedure within SQL 2005. This is a fantastic opportunity to join a very well established ...

Agenda Setters 2009
Welcome to the ninth annual Agenda Setters poll – silicon.com's list of the top 50 most influential individuals in the technology and IT industries, from techies and CIOs to entrepreneurs and business leaders. Find out more in our latest special report.





Quick Sitemap Links: