61–70 of 381 posts
One of the consequences of C is the extinguishing of machine architectures where the underlying memory model is not a flat, uniform, byte-addressed address space. Such as Symbolics or Burroughs architectures, or word-addressed machines.
C doesn't necessarily teach you how computers work. But it does teach you how software works. Our modern software empire is built on mountains of C, and deference to C is pervasive throughout higher-level software design. >You may have heard another slogan when talking about C: “C is portable assembler.” If you think about this slogan for a minute, you’ll also find that if it’s true, C cannot be how the computer work…
C at the very least teaches the difference between stack and heap memory, a crucial concept obscured by most higher-level languages.
Modern languages solve problems created developing in legacy languages (primarily C). The issue is that knowing a solution without knowing the prior problem which the solution addresses, doesn't really lend itself to clarity.
I find this article to be disingenuous. Yes, C isnt "how a computer really works". Neither is assembly. The way a computer works is based off of transistors and some concepts built on top of that (ALUs for example). However, there is no need to know about any of that because you're presented with an abstraction (assembly). And thats really what people mean when they say C is closer to how a computer actually works: i…
You can get to them from C, but via extensions. They're often very thin and will let you learn a lot about how the computer works, but it's reasonable to say that it's not really "C" at that point.
C also has more runtime that most people realize since it often functions as a de facto runtime for the whole system. It has particular concepts about how the stack works, how the heap works, how function calls work, and so on. It's thicker than you realize because you swim through it's abstractions like a fish through water, but, technically, they are not fundamental to how a computer works. A computer does not need to implement a stack and a heap and have copy-based functions and so on. There's a lot more accidental history in C than a casual programmer may realize. If nothing else compare CPU programming to GPU programming. Even when the latter uses "something rather C-ish", the resemblance to C only goes so deep.
There's also some self-fulfilling prophecy in the "C is how the computer works", too. Why do none of our languages have first-class understanding of the cache hierarchy? Well, we have a flat memory model in C, and that's how we all think about it. We spend a lot of silicon forcing our computers to "work like C does" (the specification for how registers work may as well read "we need to run C code very quickly no matter how much register renaming costs us in silicon"), and every year, that is becoming a slightly worse idea than last year as the divergence continues.
Witness any discussion of a pointer bug at any level of the stack. No matter what the piece, someone will jump in and say, "that should have been bounds checked!" A lot of times it's true. But what they miss is that the bounds check needs to come from somewhere, which means there is a layer of the system where it doesn't apply. Somewhere you have a larger piece of memory, and it gets divided into smaller chunks, and the boundaries are fiction, meaningful only to a higher level abstraction. This is the way it needs to work.
Reducing the code in which that's a concern is likely legitimate. But then you enter into "that's not really how it works".
Do you need to learn C to have a successful career in CS or any other field? No. Should you learn it? Yes. Do you need to bake bread to eat it? No. Should you learn to bake it? Yes. There are lots of things you should learn to do because they're useful and teach you about how the world works. The miracle of society is that you don't have to learn most of them to enjoy using them.
When you ask what portable assembler is, there's actually three different things you could mean:
1. C is portable assembler because every statement maps pretty directly to assembly. Obviously, compiler optimizations tend to make this completely not true (and most of the rants directed towards compiler developers are precisely because they're eschewing naive mappings).
2. You can represent every (reasonable) assembly listing using C code. Well, except that C has no notion of SIMD value (yes, there's extensions to add vector support). Until C11, it couldn't describe memory ordering. Even with compiler extensions, C still doesn't describe traps very well--any trap, in fact, is undefined behavior.
3. Every assembly instruction can have its semantics described using C code more or less natively. Again, here C has an abstract machine that doesn't correspond very well to hardware. There's no notion of things such as flag registers, and control registers are minimal (largely limited to floating-point control state). Vectors and traps are completely ignored in the model. Even more noticeably, C assigns types to values, whereas processor definitions assigns types to operations instead of values.
Note here that I didn't need to invoke undefined behavior to show how C fares poorly as portable assembler. The problem isn't that C has undefined behavior; it's that a lot of machine semantics just don't correspond well to the abstract semantics of C (or indeed most languages).
I find this article to be disingenuous. Yes, C isnt "how a computer really works". Neither is assembly. The way a computer works is based off of transistors and some concepts built on top of that (ALUs for example). However, there is no need to know about any of that because you're presented with an abstraction (assembly). And thats really what people mean when they say C is closer to how a computer actually works: i…
Even just the distinction between the stack & heap is wrong. They aren't different things, just different functions called on the otherwise identical memory. It's why things like Go work fine, because the stack isn't special. It's just memory.
malloc & free are also totally divorced from how your program interacts with the OS memory allocator, even. GC'd languages don't necessarily sit on malloc/free, so it's not like that's an underlying building block. It's simply a different building block.
So what are you trying to teach people, and is C really the way to get that concept across? Is the concept even _useful_ to know?
If you want to write fast code, which is what you'll commonly drop to C/C++ to do, then just learning C won't get you any closer to doing that. It won't teach you branch predictors, cache locality, cache lines, prefetching, etc... that are all super critical to going fast. It won't teach you data-oriented design, which is a hugely major thing for things like game engines. It won't teach you anything that matters about modern CPUs. You can _learn_ all that stuff in C, but simply learning C won't get you that knowledge at all. It'll just teach you about pointers and about malloc & free. And about heap corruption. And stack corruption.
I don't think people need to be able to code in C at the drop of a hat. But it should not be a scary thing for good engineers.
Is this not a strawman? I've never seen anyone, ever, say that C is "how the computer works". Searching for references (since the author provides pseudo-quotes to refute that they seem to have invented) finds shockingly few making such a claim.