the beauty of c

Hinzugefügt: 2026-05-12

[00:00:00]There's this clip of Linus Torvalds that I I think is pretty famous that I remember seeing at one point where he was talking to someone was asking him about C and he was saying like the the thing that I like about C is that it's it's simple enough that if you just look at any bit of C code no matter where it is, you can kind of see what the assembly for that code would look like. And today I just kind of want to talk a little bit about that and a few other related points um about why I I still see the value of C and I still um at least for how I think and for my style of programming, it fits a lot better than some other languages. So, let let's just take a look at this very basic example, right? So, where I just have these two functions, one of them is in C, one of them is in C++, I have no idea if there is a somehow a new way to iterate numbers in C++ 23.

[00:00:52]I assume these are just like two basic examples of how you could do this thing, right? Where I just have some list of numbers and I'm trying to print it out, right? And what I think Linus was getting at in that clip is that if I if I look at this C code on the left here, um where we have a print numbers function where get we're getting a pointer to the numbers array and then an integer size for that array. And then literally just making I I don't even know why I like it seems stupid to even explain this, but I'm just saying like it we're going to have one of the registers is going to be used as the counter variable. We're going to loop, check against the size variable, and then increment um like access the nums array based on that thing and call the printf function, right? That's all this code does. And it's very clear what's happening at each step, right?

[00:01:34]We've got the for loop, the comparison, the the indexing, the incrementation, the call of the function, right? Um it's very clear what's going on. And in the C++ version on the right here, like it's still very clear what's going on, right? We have we're passed a vector of numbers, we're iterating through that vector, and we're printing out each number, right? It's still very clear what the intention behind the code is, but here's the thing. I didn't implement this iterator. I've no idea how the iterator is going to work behind this means. I mean, obviously, I know what it's actually going to do, but like it practically I don't know what exact operations are going to cause that iterator to work. And then we've got like now we're using two operators, right? And whatever stood end line is, which I don't even I don't even know like what is that a type? Is it a Is it a variable? Like a constant of some type? I assume so.

[00:02:28]But like we've got now two operators, which are getting operator overloaded.

[00:02:32]So it's like still technically we're doing two function calls here, but they're now operators and not functions.

[00:02:38]So it's just like My point is that it's like when you look at the C++ code, the intent behind the computation is clear, but like what the actual assembly instructions are going to be are not, right?

[00:02:49]Um anyway, we can take a look. I pulled up I have these two I mean the function names are different, but I have these two things here um in compiler explorer.

[00:02:57]Um and my head is fully blocking that here. Maybe I should swap this around.

[00:03:01]Um all right. So like same things here. We're But you can see that it's very clear. So we got this like it seems like this is probably the main loop or whatever or maybe this is I don't know.

[00:03:12]Yeah, like [snorts] L3 is where the main loop is and you can see we're just going to be putting the stuff into the registers.

[00:03:18]Uh it seems like here is where they're doing the array indexing. Um and then here's where they're doing the comparison and then the jump test, right? It's very clear like what I said is what the assembly looks like, right?

[00:03:30]And in the C++ version um this the Okay, wait.

[00:03:38]Am I stupid? There we go. Okay.

[00:03:39]It's like [snorts] obviously um it's just a lot more, right? I mean, we can still see like we're now we're calling the out the iterator just there and then we're doing we're calling like the operators on these streams and stuff, right? Um and now, I think the the first and most obvious counter argument to this is like, obviously you're not doing any optimizations, right? Uh and now, this is actually kind of an interesting example. So, this is the optimized version with C. Um where I mean, it's still basically the same thing. I It seems like we're directly um incrementing that instead of doing that LEA instruction, but like we're still calling printf and stuff. Um whereas in this version, >> [snorts] >> oh, this was actually Okay, well, this version still is doing stuff. It seemed like I think they've they've definitely optimized some of it, but when I went ahead and swapped this actually with the printf that I'm using in the other version, um was interesting to me. This is actually like uh and from what I can tell, more optimized than the other version.

[00:04:40]Um it seemed like it somehow rolled in the um like the indexing of the array with the loop increment or something. I don't know. I honestly I'm not I'm not an expert on assembly. But, that that is an interesting point where it's like cuz the intention behind this one was clear, the compiler's actually able to optimize it more. Um but yeah, let's let me pull up this canvas here.

[00:05:01]Um Uh here we go. So, what I'm getting at here is that we have when whenever you're programming, right?

[00:05:10]There is some sort of computation that where this is like the end goal, right? Like you're the point of writing your program is to encode this computation that's happening, right? Like the I I mean, maybe that's a little bit reductive, but like that's literally just the goal of what a program is, right? But, here's the thing is that what's actually going to be running that is is not like some nebulous like Turing machine, right? It's an actual computer, right?

[00:05:43]And this computer runs on instructions, right? So, we'll say like ASM.

[00:05:50]>> [snorts] >> I don't know. I mean, this is all various. I'm just trying to like spell out this argument of like why I think this way. Or so, in reality, the program it it encodes some computation, but what's actually happening is that the compiler um it has to translate what computation you intended into assembly, which is then is run on a computer, right? Um so, like you have some intention of the computation that's going to happen. And it is going to do that computation, but it's going to do it through this assembly here, right? Um so, what what actually matters in the real world when it's running on a computer is not what you desired for the computation to be, but what the actual assembly instructions that the compiler generated are going to be. Hopefully, that makes sense, right? And what I was getting at earlier with the two examples, right? Is that in in the C version, right? We we have the desired computation, right? That's clear in the C version. We we want to loop through this list of numbers and print it out.

[00:06:55]But, it's also very clear what that assembly is going to look like. So, what our desired computation is and what our actual computation that's going to get done on the computer, those two are very closely aligned, right? And what in a higher lang- higher level language, maybe not higher level is the right word, but in a more flexible, more expressive language like modern C++, the the computation is still very clear. I honestly I would argue in some cases it can be more clear um in terms of what the intent behind the computations, but it's less clear how that computation is actually going to get done. And I think that does I think that does matter in a lot of cases. Um and I I mean, honestly, one of the simple ones is literally just operator overloading. So, like if you have a line of code where you say C equals A plus B. Well, like there's a whole line of code. In In C, you know exactly exactly what this means, right? Because in C, this would have to be A, B, and C all have to be the same type. Well, I mean, they could be different numeric types, right? But they're all either pointers or all numeric types. And you know exactly what the equals is going to do.

[00:08:06]You know exactly what the plus is going to do. But if you look at this code in a C++ code base, it could literally be like connecting to the internet or like loading a file. Like because you know overload operators, there's no way to know what the actual effective computation is going to be even though the intent of the computation is clear, right? So, like another way of looking at this, um which I think is kind of the more important point almost, is that in when you're coding in C, when you're coding in a language as simple as C, and I honestly maybe something like Zig or Odin are also like this. I just don't have enough experience with those, but it's almost like I'm I'm trying like I I I I hesitate to use the term position-independent code cuz that means like a very specific thing when it comes to linking, but like it it's almost like the code that you have in isolation in a single body of a function um is completely understandable without the context of the entire rest of the code base, right? Like if you see this line, C equals A plus B in any spot in any C code base, like macro shenanigans notwithstanding, you're going to know that these are all types that are pointers to numeric and they're they're going to operate as if you were expecting them, right? But if this was in C++, like these could be A and B could be like vectors or I don't know I don't know if vectors actually support the add operator, but like these could be concatenating two lists and then like copying that to C or moving that to C.

[00:09:32]And you just get into all this stuff where computation is being done and it's not obvious that a computation is being done, right? I think if from what I know, I think this is a very important thing in like the whole Zig philosophy, but like in C++, there's so much stuff with like constructors, deconstructors, move semantics, copy semantics, something simple that looks simple in the code could actually be doing like a million billion things, right? And the beauty of C, the beauty of C, it's so simple, and it's so like independent of what the specific code base is that you can literally like go into code pretty much anywhere and understand what it's going to be doing. Like a return is always the same, pointers always work the same, like you don't have references, so it's not like if you have some equals in a function body, it's not like is that an argument and we have a copy of the argument or is that a reference?

[00:10:25]Like there's none of that. Uh and it's just it's very clear how your desired computation is going to translate to um the actual computation, right? We're coming back to this whole diagram. And like in fairness, I think that it is um you could make an argument that it's actually better to do it more toward the C++, more toward the Rust end of things because what matters is the actual computation that you want, not how the computer is going to execute that, and if you're dealing with more higher-level concepts, the compiler will have more context as to what your actual intent behind the code is, whether or not your um like the way that you're trying to achieve that intent is the most optimized way. I don't know if that makes sense, but like my main point is that I I like the fact that C is very clear what the actual effect of computation will be, and it's never going to change based on what code base you're in. And there's not going to be um again, macros notwithstanding, I don't know if there there may be some other exceptions that I'm not familiar with, but like there's not going to be computation that's happening that's not a literal line of code in the current function body, right? Like it's it's always very clear what's actually going on. And I think those two things in conjunction are really um where the powers of C comes in and where the relevancy of C still is to this day.

[00:11:50]Cuz honestly, like something like Odin or Zig, I think you still get that um sort of position independent thing where it like it doesn't matter what code base you're in, but you unless I'm mistaken here, you kind of lose a little bit of the direct translation into assembly with some of their higher level more syntactic sugar things.

[00:12:09]Um yeah, I don't know. That was just some thoughts I had. Um I I wanted to hear really would love to hear your thoughts about this cuz I know um a lot of C nerds in my audience, no offense.

[00:12:20]We're one of us, right? But uh just let me know. And this is this is just something that I was thinking about recently. Yeah.