Bjarne Stroustrup: C++ | Lex Fridman Podcast #48

The following is a conversation with Bjarn Stroustrup. He is the creator of C, a programming language that after 40 years is still one of the most popular and powerful languages in the world. Its focus on fast, stable, robust code underlies many of the biggest systems in the world that we have come to rely on as a society. If you're watching this on YouTube, for example, many of the critical backend components of YouTube are written in C. Same goes for Google, Facebook, Amazon, Twitter, most Microsoft applications, Adobe applications, most database systems, and most physical systems that operate in the real world, like cars, robots, rockets that launch us into space and one day will land us on Mars. C also happens to be the language that I use more than any other in my life. I've written several hundred thousand lines of C source code. Of course, lines of source code don't mean much, but they do give hints of my personal journey through the world of software. I've enjoyed watching the development of C as a programming language leading up to the big update in the standard in 2011 and those that followed in 1417 and toward the new C20 standard, hopefully coming out next year. This is the Artificial Intelligence podcast. If you enjoy it, subscribe on YouTube, give it five stars on iTunes, support it on Patreon, or simply connect with me on Twitter lexfriedman, spelled F R I D M A N. And now here's my conversation with Bjorn Strausstrup. What was the first program you've ever written? Do you remember?

It was my second year in university, first year of computer science and it was an Algol 60. I calculated the shape of super ellipse and then connected points on the perimeter creating star patterns. It was with wet ink on paper printer.

And that was in college. University.

Yeah. Yeah. I learned to program the second year in university.

And what was the first programming language, if I may ask it this way, that you fell in love with?

I. I think I'll call 60. And after that I remember, I remember Snowball, I remember Fortran. Didn't fall in love with that. I remember Pascal. Didn't fall in love with that. It all got in the way of me. And then I discovered assembler and that was much more fun. And from there I went to microcode.

So you were drawn to the. You found the low level stuff beautiful.

I, I went through a lot of languages and then I spent significant time in assembler and microcode. That was sort of the first really profitable things. And I paid for my masters, actually. And then I discovered Simula, which was absolutely great. Simula Simula was the extension of Algol 60 done primarily for simulation, but basically they invented object oriented programming at inheritance and runtime polymer while they were doing it. And that was the language that taught me that you could have the sort of the problems of a program grow with size of the program rather than with the square of the size of the program. That is, you can actually modularize very nicely. And that was a surprise to me. It was also a surprise to me that a stricter type system than Pascal's was helpful, whereas Pascal's type system got in my way all the time. So you need a strong type system to organize your code well, but it has to be extensible and flexible.

Let's get into the details a little bit. If you remember, what kind of type system did Pascal have? What type system typing system did Algol 60 have?

Basically, Pascal was sort of the simplest language that Nicolaus Wirth could define, that served the needs of Nicholas Wirth at the time. And it has a sort of a highly moral tone to it. That is, if you can say it in Pascal, it's good, and if you can't, it's not so good. Whereas Simula allowed you basically to build your own type system. So instead of trying to fit yourself into Niklaus Wirtz's world, Christ Nugel's language and language allowed you to build your own. So it's sort of close to the original idea of you build a domain specific language. As a matter of fact, what you build is a set of types and relations among types that allows you to express something that's suitable for an application.

So when you say types, stuff you're saying has echoes of object oriented programming.

Yes, they invented it. Every language that uses the word class for type is a descendant of Simula, directly or indirectly. Kristen Nygo and Ol Johandahl were mathematicians, and they didn't think in terms of types, but they understood sets and classes of elements. And so they called their types classes. And basically in C, as in similar classes are user defined type.

So can you try the impossible task and give a brief history of programming languages from your perspective? So we started with Algol 60, Simula, Pascal, but that's just the 60s and.

70S I can try. The most sort of interesting and major improvement of programming languages was Fortran, the first Fortran, because before that all code was written for a specific machine, and each specific machine had a language, assembly language, or macro assembler, or some extension of that idea. But you are writing for a specific machine in the language of that machine. And Bachus and his team at IBM built a language that would allow you to write what you really wanted. That is, you could write it in a language that was natural for people. Now these people happened to be engineers and physicists, so the language that came out was somewhat unusual for the rest of the world. But basically they said formula translation because they wanted to have the mathematical formulas translated into the machine. And as a side effect they got portability because now they are writing in the terms that the humans used and the way humans thought. And then they had a program that translated it into the machine's needs. And that was new and that was great. And it's something to remember. We want to raise the language to the human level, but we don't want to lose the efficiency. So.

And that was the first step towards the human.

That was the first step. And of course they were very particular kind of humans. Business people were different. So they got Coborn instead and et cetera, et cetera. And Simula came out. No, let's not go to Simula yet. Let's go to Algor. Fortran didn't have at the time the notions of not a precise notion of type, not a precise notion of scope, not a set of translation phases. That was what we have today, lexical syntax, semantics. It was sort of a bit of a model in the early days. But hey, they're just on the biggest breakthrough in the history of programming, right? So you can't criticize them for not having gotten all the technical details right. So we got alcohol, that was very pretty. And most people in commerce and science considered it useless because it was not flexible enough and it wasn't efficient enough and et cetera, et cetera. But that was a breakthrough from the technical point of view. Then similar came along to make that idea more flexible and you could define your own types. And that's where I got very interested. Who's the main idea man behind Simula?

That was late 60s.

This was late 60s. Well, I was a visiting professor in AUS and so I learned object oriented programming by sitting around and well, in theory discussing with Kristen Nugel. But Kristen, once you get started and in full flow, it's very hard to get a word niche ways with.

You're just listening.

So it was great. I learned it from there.

Not to romanticize the notion, but it seems like a big leap to think about object oriented programming. It's really a leap of abstraction.

Yes.

And was that as big and beautiful of a leap as it seems from now in retrospect, or was it an.

Obvious one at the time, it was not obvious. And many people have tried to do something like that. And most people didn't come up with something as wonderful as similar. Lots of people got their PhDs and made their careers out of forgetting about Simula or never knowing it. For me, the key idea was basically I could get my own types. And that's the idea that goes further into C, where I can get better types and more flexible types and more efficient types. But it's still the fundamental idea. When I want to write a program, I want to write it with my types of that is appropriate to my problem and under the constraints that I'm under with hardware, software, environment, et cetera. And that's the key idea. People picked up on the class hierarchies and the virtual functions and the inheritance. And that was only part of. Was an interesting and major part, and still a major part in a lot of graphic stuff. But it was not the most fundamental. It was when you wanted to relate one type to another, you don't want them all to be independent. The classical example is that you don't actually want to write city simulation with vehicles with where you say, well, if it's a buy signal, write the code for turning a buy signal to the left. If it's a normal car, turn right the normal car way. If it's a fire engine, turn right the fire engine way. Da da da da da da. You get these big case statements and bunches of if statements and such. Instead you tell the base class that's the vehicle and saying turn left the way you want to. And this is actually a real example. They used it to simulate and optimize the emergency. The emergency services for somewhere in Norway back in the 60s.

Wow.

So this was one of the early examples for why you needed inheritance and you needed a runtime polymorphism because you wanted to handle this set of vehicles in a manageable way. You can't just rewrite your code each time a new kind of vehicle comes along.

Yeah, that's a beautiful, powerful idea. And of course it stretches through your work with C, as we'll talk about, but I think you structured it nicely. What other breakthroughs came along in the history of programming languages if we were to tell the history in that way?

Obviously I'm better telling the part of the history that is the path I'm on. As opposed to all the paths.

Yeah, you skipped the hippie John McCarthy and Lisp, one of my favorite languages.

But Lisp is not one of my favorite languages. It's Obviously important, it's obviously interesting. Lots of people write code in it and then they rewrite it into C or C when they want to go to production. Yes, it's in the world I'm at which are constrained by performance, reliability issues, deployability, cost of hardware. I don't like things to be too dynamic. It is really hard to write a piece of code that's perfectly flexible, that you can also deploy on a small computer and that you can also put in, say, a telephone switch in Bogota. What's the chance if you get an error and you find yourself in the debugger that the telephone switch in Bogota on late Sunday night has a programmer around? The chance is zero. And so a lot of things I think most about can't afford that flexibility. I'm quite aware that maybe 70, 80% of all code are not under the kind of constraints I'm interested in. But somebody has to do the job I'm doing because you have to get from these high level flexible languages to the hardware.

The stuff that lasts for 10, 20, 30 years is robust, operates under very constrained conditions. Yes, absolutely, that's right. And it's fascinating and beautiful in its own way. C is one of my favorite languages and so is Lisp. So I can embody two for different reasons.

As a programmer, I understand why Lisp is popular and I can see the beauty of the ideas. And similarly with small talk, it's just not a relative, it is not as relevant in my world. And by the way, I distinguish between those functional languages where I go to things like ML and Haskell, different kind of languages, they have a different kind of beauty and they're very interesting. And I actually try to learn from all the languages I encounter to see what is there that would make working on the kind of problems I'm interested in, with the kind of constraints that I'm interested in, what can actually be done better, because we can surely do better than we do today.

You've, you've said that it's good for any professional programmer to know at least five languages as speaking about a variety of languages that you've taken inspiration from and you've listed yours as being, at least at the time, C, obviously. Java, Python, Ruby and JavaScript. Can you first of all update that list, modify it? You don't have to be constrained to just five. But can you describe what you picked up also from each of these languages, how you see them as inspirations for even you working with C?

This is a very hard question to answer. So about languages, you should Know languages. I reckon I knew about 25 or thereabouts when I did C. It was easier in those days because the languages were smaller and you didn't have to learn a whole programming environment and such to do it. You could learn the language quite easily. And it's good to learn so many languages.

And I imagine just like with natural language for communication, there's different paradigms that emerge in all of them. Yeah, that there's commonalities and so on.

So I picked five out of a hat.

You picked five out of a hat.

Obviously the important thing that the number is not one.

That's right.

It's like I don't like. I mean if you're a monoglot you are likely to think that your own culture is the only ones periods of everybody else's. A good learning of a foreign language and a foreign culture is important. It helps you think and be a better person. With programming languages you become a better programmer, better designer with the second language. Now once you've got two, the weight of five is not that long. It's the second one that's most important. And then when I had to pick five, I thinking what kinds of languages are there? Well, there's a really low level stuff. It's actually good to know machine code even still.

Sorry, even today.

Even today the C optimizers write better machine code than I do. But I don't think I could appreciate them if I actually didn't understand machine code and machine architecture. At least in my position I have to understand a bit of it because you mess up the cache and you're off in performance by a factor of 100. Right. It shouldn't be that if you are interested in either performance or the size of the computer you have to deploy. So I would go as a simpler. I used to mention C. But these days going low level is not actually what gives you the performance. It is to express your ideas so cleanly that you can think about it and the optimizer can understand what you're up to. My favorite way of optimizing these days is to throw out the clever bits and see if it still runs fast and sometimes it runs faster. So I need the abstraction mechanisms or something like C to write compact high performance code. There was a beautiful keynote by Jason Turner at the cppcon a couple of years ago where he decided he was going to program pong on Motorola 6800, I think it was. And he says, well, this is relevant because it looks like a microcontroller, it has specialized Hardware, it has not very much memory and it's relatively slow. And so he shows in real time how he writes Pong, starting with fairly straightforward low level stuff, improving his abstractions and what he's doing. He's writing C and it translates into 86 is simpler, which you can do with clang. And you can see it in real time. It's the compiler explorer, which you can use on the web. And then he wrote a little program that translated 86 assembler into Motorola assembler. And so he types and you can.

See this thing in real time. Wow.

You can see it in real time. And even if you can't read the assembly code, you can just see it. His code gets better, the code, the assembler gets smaller, he increases the abstraction level, uses C11 as it were, better. This code gets cleaner, it gets easier, maintainable, and the code shrinks and it keeps shrinking. And I could not in any reasonable amount of time write that assembler as good as the compiler. Generated from really quite nice modern C. And I'll go as far as to say that the thing that looked like C was significantly uglier and smaller when it became and larger when it became machine code. So the abstractions that can be optimized are important.

I would love to see that kind of visualization in larger code bases. Yeah, that might be beautiful.

Can't show a larger code base in a one hour talk and have it fit on screen.

Right. So that's C and C. So my.

Two languages would be machine code and C. And then I think you can learn a lot from the functional languages. So Pig, Haskell, ML, I don't care which. I think actually you learn the same lessons of expressing especially mathematical notions really clearly and having a type system that's really strict. And then you should probably have a language for sort of quickly churning out something. You could pick JavaScript, you could pick Python, you could pick Ruby.

What do you make of JavaScript in general? So you kind of. You're talking in the Platonic sense about languages, about what they're good at, what their philosophy of design is. But there's also a large user base behind each of these languages and they use it in the way sometimes maybe it wasn't really designed for.

That's right.

JavaScript is used way beyond probably what it was designed for.

Let me say it this way. When you build a tool, you do not know how it's going to be used. You try to improve the tool by looking at how it's being used. And when people cut their fingers off and try and stop that from happening. But really you have no control over how something is used. So I'm very happy and proud of some of the things C is being used at and some of the things I wish people wouldn't do. Bitcoin mining being my favorite example, uses as much energy as Switzerland and, and mostly serves criminals. But back to the languages, I actually think that having JavaScript run in the browser was an enabling thing for a lot of things. Yes, you could have done it better, but people were trying to do it better and they were using sort of more principles, language designs, but they just couldn't do it right. And the non professional programmers that write lots of that code just couldn't understand them. So it did an amazing job for what it was. It's not the prettiest language and I don't think it ever will be the prettiest language, but let's not be bigots here.

So what was the origin story of C? You, 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, what's reliability?

I, I, 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, 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, to, to have reliability of larger systems. If you spend all your time interpreting a, 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, 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.

So how do you inspire or ensure that the Einstein level of simplification is reached? So can you do code review? Can you look at code is there? If I gave you the code for the Ford F150 and said here, is this a mess or is this okay? Is it possible to tell? Is it possible to regulate?

An experienced developer can look at code and see if it smells mixed metaphors deliberately. The point is that it is hard to generate something that is really obviously clean and can be appreciated, but you can usually recognize when you haven't reached that point. And so I've never looked at the IF150 code, so I wouldn't know. But I know what I ought to be looking for. I'll be looking for some tricks that correlates with bugs and elsewhere. And I have tried to formulate rules for what good code looks like. The current version of that is called the C Core Guidelines. One thing people should remember is there's what you can do in a language and what you should do in a language. You have lots of things that is necessary in some context, but not in others, as things that exist. Just because there's 30 year old code out there and you can't get rid of it, but you can have rules that says when you create it, try and follow these rules. This does not create good programs by themselves, but it limits the damage from mistakes, it limits the possibilities of the mistakes. And basically we are trying to say, what is it that a good programmer does at the fairly simple level of where you use the language and how you use it? Now I can Put all the rules for chiseling and marble. It doesn't mean that somebody who follows all of those rules can do a masterpiece by Michelangelo. That is, there's something else to write a good program. Just is there something else to create important work of art that is some kind of inspiration, understanding, gift? But we can approach the sort of technical, the craftsmanship level of it. The famous painters, the famous sculptures was, among other things, superb craftsmen. They could express their ideas using their tools very well. And so these days, I think what I'm doing, what a lot of people are doing, we are still trying to figure out how it is to use our tools very well. For a really good piece of code, you need a spark of inspiration. And you can't, I think, regulate that. You cannot say that I'll take a picture only, I'll buy your picture, only if you're at least van Gogh. There are other things you can regulate, but not the inspiration.

I think that's quite beautifully put. It is true that there is, as an experienced programmer, when you see code that's inspired, that's like Michelangelo, you know it when you see it. And the opposite of that is code that is messy code that smells, you know when you see it. And I'm not sure you can describe it in words, except vaguely through guidelines and so on.

Yes, it's easier to recognize ugly than to recognize beauty in code. And for the reason is that sometimes beauty comes from something that's innovative and unusual. And you have to sometimes think reasonably hard to appreciate that. On the other hand, the messes have things in common. And you can have static checkers and dynamic checkers and fines, a large number of the most common mistakes. You can catch a lot of sloppiness mechanically. I'm a great fan of static analysis in particular, because you can check for not just the language rules, but for the usage of language rules. And I think we will see much more static analysis in the coming decade.

Can you describe what static analysis is?

You represent a piece of code so that you can write a program that goes over that representation and look for things that are right and not right. So, for instance, you can analyze a program to see if resources are leaked. That's one of my favorite problems. It's not actually all that hard in modern C, but you can do it. If you're writing in the C level, you have to have a malloc and a free, and they have to match. If you have them in a single function, you can usually do it very easily. If there's a malloc here, there should be a free there. On the other hand, in between can be true in complete code. And then it becomes impossible if you pass that pointer to the memory out of a function and then want to make sure that the free is done somewhere else. Now it gets really difficult. And so for static analysis, you can run through a program and you can try and figure out if there's any leaks. What you will probably find is that you will find some leaks and you'll find quite a few places where your analysis can't be complete. It might depend on runtime, it might depend on the cleverness of your analyzer, and it might take a long time. Some of these programs run for a long time, but if you combine such analysis with a set of rules that says how people could use it, you can actually see why the rules are violated. And that stops you from getting into the impossible complexities. You don't want to solve the holding problem.

So static analysis is looking at the code without running the code?

Yes.

And thereby it's almost not in production code, but it's almost like an educational tool of how the language should be used. It guides you like it at its best. Right. It would guide you in how you write future code as well. And you learn together.

Yes. So basically you need a set of rules for how you use the language. Then you need a static analysis that catches your mistakes when you violate the rules, or when your code ends up doing things that it shouldn't, despite the rules, because there's the language rules. We can go further. And again, it's back to my idea that I'd much rather find errors before I start running the code. If nothing else, once the code runs, if it catches an error at runtimes, I have to have an error handler. And one of the hardest things to write in code is error handling code because you know something went wrong. Do you know really exactly what went wrong? Usually not. How can you recover when you don't know what the problem was? You can't be 100% sure what the problem was in many, many cases, and this is part of it. So yes, we need good languages with good type systems. We need rules for how to use them. We need static analysis. And the ultimate for static analysis is of course program proof, but that still doesn't scale to the kind of systems we deploy. Then we start needing testing and the rest of the stuff.

So C is an object oriented programming language that creates, especially with its newer versions, as we'll talk about higher and higher levels of abstraction. So how do you design? Let's even go back to the origin of C. How do you design something with so much abstraction that's still efficient and is still something that you can manage, do static analysis on, you can have constraints on, they can be reliable, all those things we've talked about. So create the. The. To me slightly, there's a slight tension between high level abstraction and efficiency.

That's a good question. I could probably have a year's course just trying to answer it. Yes, there's a tension between efficiency and abstraction. But you also get the interesting situation that you get the best efficiency out of the best abstraction. And my main tool for efficiency, for performance actually is abstraction. So let's go back to how C got there. You said it was object oriented programming language. I actually never said that. It's always quoted, but I never did. I said C supports object oriented programming, but it's not. And other techniques. And that's important because I think that the best solution to most complex, interesting problems require ideas and techniques from things that have been called object oriented data abstraction, functional traditional C style code, all of the above. And so when I was designing C, I soon realized I couldn't just add features. If you just add what looks pretty or what people ask for or what you think is good one by one, you're not going to get a coherent whole. What you need is a set of guidelines that guides your decisions. Should this feature be in or should this feature be out? How should a feature be modified before it can go in and such. And there's a. In the book I wrote about that, the Design and Evolution of C, there's a whole bunch of rules like that. Most of them are not language technical. There are things like don't violate static type system. Because I like static type system for the obvious reason that I like things to be reliable on reasonable amounts of hardware. But one of these rules is the zero overhead principle. What kind of principle? The zero overhead principle. It basically says that if you have an abstraction, it should not cost anything compared to write the equivalent code at a lower level. So if I have, say, a matrix multiply, it should be written in such a way that you could not drop to the sea level of abstraction and use arrays and pointers and such and run faster. People have written such matrix multiplications and they have actually gotten code that ran faster than fortran because once you had the right abstraction, you can eliminate temporaries and you can do loop fusion and other good stuff like that. That's quite hard to do by hand. And in a lower level language. And there's some really nice examples of that. And the key here is that that matrix multiplication, the matrix abstraction, allows you to write code that's simple and easy. You can do that in any language. But with C, it has the features so that you can also have this thing run faster than if you hand coded it. Now, people have given that lecture many times, I and others, and a very common question after the talk where you have demonstrated that you can outperform Fortran for dense matrix multiplication, people come up and says, yeah, but there's C. If I rewrote your code in C, how much faster would it run? The answer is much slower. This happened the first time, actually, back in the 80s with a friend of mine called Doug McElroy who demonstrated exactly this effect. The principle is you should give programmers the tools so that the abstractions can follow the zero principle. Furthermore, when you put in a language feature in C or a standard library feature, you try to meet this. It doesn't mean it's absolutely optimal, but it means if you hand code it with the usual facilities in the language in C, in C, you should not be able to better it. Usually you can do better if you use embedded assembler for machine code, for some of the details to utilize part of a computer that the compiler doesn't know about. But you should get to that point before you beat the abstraction.

So that's a beautiful ideal to reach for.

And we meet it quite often.

Quite often. So where's the magic of that coming from? There's some of it is the compilation process, so the implementation of C. Some of it is the design of the feature itself, the guidelines. So I've recently and often talked to Chris Lattner, so. Clang. What, just out of curiosity, is your relationship in general with the different implementations of C? As you think about, you and committee and other people in C, think about the design of new features or design of previous features in trying to reach the ideal of zero overhead. Does the magic come from the design.