- What was the origin story of C++? You basically gave a few perspectives of your inspiration of object-oriented programming. That's, you had a connection with C and performance. Efficiency was an important, a thing you were drawn to. - Efficiency and reliability. - Reliability. - You have to get both.

- What's reliability? - I really want my telephone calls to get through and I want the quality of what I am talking, coming out at the other end. The other end might be in London or wherever. So, and you don't want the system to be crashing. If you're doing a bank, you mustn't crash.

It might be your bank account that is in trouble. There's different constraints, like in games, it doesn't matter too much if there's a crash, nobody dies and nobody gets ruined. But I'm interested in the combination of performance, partly because of sort of speed of things being done, part of being able to do things that is necessary to have reliability of larger systems.

If you spend all your time interpreting a simple function call, you are not going to have enough time to do proper signal processing to get the telephone calls to sound right. Either that, or you have to have 10 times as many computers and you can't afford your phone anymore.

It's a ridiculous idea in the modern world because we have solved all of those problems. - I mean, they keep popping up in different ways. 'Cause we tackle bigger and bigger problems, so efficiency remains always an important aspect. - But you have to think about efficiency, not just as speed, but as an enabler to important things.

And one of the things it enables is reliability, is dependability. When I press the pedal, the brake pedal of a car, it is not actually connected directly to anything but a computer. That computer better work. - Let's talk about reliability just a little bit. So modern cars have ECUs, have millions of lines of code today.

So this is certainly, especially true of autonomous vehicles where some of the aspects of the control or driver assistance systems that steer the car, that keep it in the lane and so on. So how do you think, you know, I talked to regulators, people in government who are very nervous about testing the safety of these systems of software, ultimately software that makes decisions that could lead to fatalities.

So how do we test software systems like these? - First of all, safety, like performance and like security, is a system's property. People tend to look at one part of a system at a time and saying something like, this is secure. That's all right, I don't need to do that.

Yeah, that piece of code is secure, I'll buy your operator. - Right. - If you want to have reliability, if you want to have performance, if you want to have security, you have to look at the whole system. - I did not expect you to say that, but that's very true, yes.

- I'm dealing with one part of the system and I want my part to be really good, but I know it's not the whole system. Furthermore, making an individual part perfect may actually not be the best way of getting the highest degree of reliability and performance and such. There's people who say C++ is type safe, not type safe, you can break it.

Sure, I can break anything that runs on a computer. I may not go through your type system. If I wanted to break into your computer, I'll probably try SQL injection. - And it's very true, if you think about safety or even reliability at a system level, especially when a human being is involved, it starts becoming hopeless pretty quickly in terms of proving that something is safe to a certain level.

- Yeah. - 'Cause there's so many variables, it's so complex. - Well, let's get back to something we can talk about and actually make some progress on. - Yes. - We can look at C++ programs and we can try and make sure they crash less often. The way you do that is largely by simplification.

It is not, the first step is to simplify the code, have less code, have code that are less likely to go wrong. It's not by runtime testing everything. It is not by big test frameworks that you're using. Yes, we do that also. But the first step is actually to make sure that when you want to express something, you can express it directly in code rather than going through endless loops and convolutions in your head before it gets down the code.

That if the way you are thinking about a problem is not in the code, there is a missing piece that's just in your head. And the code, you can see what it does, but it cannot see what you thought about it unless you have expressed things directly. When you express things directly, you can maintain it.

It's easier to find errors. It's easier to make modifications. It's actually easier to test it. And lo and behold, it runs faster. And therefore you can use a smaller number of computers, which means there's less hardware that could possibly break. So I think the key here is simplification, but it has to be, to use the Einstein quote, "As simple as possible and no simpler." - Not simpler.

- But there are other areas with under constraint where you can be simpler than you can be in C++, but in the domain I'm dealing with, that's the simplification I'm after. (air whooshing) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music)