Bjarne Stroustrup argues that efficiency and reliability must be pursued together, not separately. He points out that modern cars contain millions of lines of code across multiple systems, making safety testing for autonomous driving extremely difficult. Simplification, not perfection of individual components, is what actually enables dependable systems.
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 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 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 because 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 aspect of the control or driver assistance systems that steer the car to keep it in the lane and so on. So how do you think, you know, I talk to regulators, people in the 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 you, how do we test software systems like these?
First of all, safety, like performance and like security is the 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 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 C, 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.
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 because 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. We can look at C programs and we can try and make sure they crash. This 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 are 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. 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. There are other areas with under constraints 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. SA.
