3 ms·

> a very thin abstraction over assembly. I think this statement implies that it’s clear and obvious what assembly will be generated from a snippet of C/C++ cod

> a very thin abstraction over assembly. I think this statement implies that it’s clear and obvious what assembly will be generated from a snippet of C/C++ code. But few people can understand everything that optimising compilers and modern processors do to normal looking code. An example of this lack of knowledge is seeing people disagree on if a snippet contains UB or not. If C is so simple, why do people struggle to write it?

skohan 5y ago
> But few people can understand everything that optimising compilers and modern processors do to normal looking code. Well when I'm talking about an abstraction over assembly I'm not talking about optimizing compilers. That's another topic entirely. What I mean is, if you look at a block of C code, it's very easy to understand what the machine is doing. > If C is so simple, why do people struggle to write it? Do they? I think people struggle to write correct, bug-free code in C, but that's because it doesn't save you from yourself, and it's happy to let you do whatever the hardware will do. That's a much larger programmable space than the set of all safe correct programs. But I don't think people in general have difficulty looking at a snippet of C code and understanding it.
- nindalf 5y ago
  > What I mean is, if you look at a block of C code, it's very easy to understand what the machine is doing. So they simultaneously understand what the machine is doing but don’t know what assembly will be generated? Both can’t be true. If everyone understood what the machine was doing, everyone would be able to look at a snippet and agree - “that’s UB, let’s not do that”. But they can’t agree. Because few people understand what the compiler and the processor will do. The “thin layer of assembly” was true for the first generation of C compilers. But it hasn’t been true for a long time. It’s a complete black box now. Anyone who thinks that it’s straightforward isn’t being upfront with themselves.
  - skohan 5y ago
    > So they simultaneously understand what the machine is doing but don’t know what assembly will be generated? Both can’t be true. I mean I can understand a reasonable mapping to what the un-optimized assembly would be. Compiler optimization is very complex, and is going to obscure the results in every language. > If everyone understood what the machine was doing, everyone would be able to look at a snippet and agree - “that’s UB, let’s not do that”. But they can’t agree. Because few people understand what the compiler and the processor will do. What? I think everyone can agree that UB is much harder to detect in assembly than in higher level languages than assembly, and assembly gives the most clear view of what the machine is doing. It's a very complex topic to create a system which detects and disallows UB automatically in the compiler - this requires a lot more complexity than a simple mapping of high level instructions to machine instructions. > The “thin layer of assembly” was true for the first generation of C compilers. But it hasn’t been true for a long time. It’s a complete black box now. Anyone who thinks that it’s straightforward isn’t being upfront with themselves. I don't know, seems pretty straightforward to me: https://godbolt.org https://godbolt.org
    - nindalf 5y ago
      Let me rephrase. You say C is simple. I say Rust (for example) is simple. I can look at a Rust code base and say confidently - this code base has no UB in it, it has no memory safety issues in it. Can you look at a non trivial C code base and make such an assertion? You can’t. Even simple looking C code could be translated into problematic assembly because such a transformation is technically valid. And it’s beyond the ability of anyone but an expert to guard against that. C is a very useful language. Very important. Very fast. A great tool in the right hands. The world wouldn’t run without it. And it will remain useful and important and fast for decades to come, certainly. But it’s not simple and hasn’t been for a long time. Let’s acknowledge that.
      - skohan 5y ago
        I'm sorry I don't understand your argument at all. What does lack of UB and memory safety have to do with simplicity? Those are very complex features of Rust which require a very complex compiler in order to achieve. Also Rust is notorious for having a steep learning curve, and it takes time for even very experienced programmers to become accustomed to it.

skohan 5y ago

> But few people can understand everything that optimising compilers and modern processors do to normal looking code. Well when I'm talking about an abstraction over assembly I'm not talking about optimizing compilers. That's another topic entirely. What I mean is, if you look at a block of C code, it's very easy to understand what the machine is doing. > If C is so simple, why do people struggle to write it? Do they? I think people struggle to write correct, bug-free code in C, but that's because it doesn't save you from yourself, and it's happy to let you do whatever the hardware will do. That's a much larger programmable space than the set of all safe correct programs. But I don't think people in general have difficulty looking at a snippet of C code and understanding it.

nindalf 5y ago
> What I mean is, if you look at a block of C code, it's very easy to understand what the machine is doing. So they simultaneously understand what the machine is doing but don’t know what assembly will be generated? Both can’t be true. If everyone understood what the machine was doing, everyone would be able to look at a snippet and agree - “that’s UB, let’s not do that”. But they can’t agree. Because few people understand what the compiler and the processor will do. The “thin layer of assembly” was true for the first generation of C compilers. But it hasn’t been true for a long time. It’s a complete black box now. Anyone who thinks that it’s straightforward isn’t being upfront with themselves.
- skohan 5y ago
  > So they simultaneously understand what the machine is doing but don’t know what assembly will be generated? Both can’t be true. I mean I can understand a reasonable mapping to what the un-optimized assembly would be. Compiler optimization is very complex, and is going to obscure the results in every language. > If everyone understood what the machine was doing, everyone would be able to look at a snippet and agree - “that’s UB, let’s not do that”. But they can’t agree. Because few people understand what the compiler and the processor will do. What? I think everyone can agree that UB is much harder to detect in assembly than in higher level languages than assembly, and assembly gives the most clear view of what the machine is doing. It's a very complex topic to create a system which detects and disallows UB automatically in the compiler - this requires a lot more complexity than a simple mapping of high level instructions to machine instructions. > The “thin layer of assembly” was true for the first generation of C compilers. But it hasn’t been true for a long time. It’s a complete black box now. Anyone who thinks that it’s straightforward isn’t being upfront with themselves. I don't know, seems pretty straightforward to me: https://godbolt.org https://godbolt.org
  - nindalf 5y ago
    Let me rephrase. You say C is simple. I say Rust (for example) is simple. I can look at a Rust code base and say confidently - this code base has no UB in it, it has no memory safety issues in it. Can you look at a non trivial C code base and make such an assertion? You can’t. Even simple looking C code could be translated into problematic assembly because such a transformation is technically valid. And it’s beyond the ability of anyone but an expert to guard against that. C is a very useful language. Very important. Very fast. A great tool in the right hands. The world wouldn’t run without it. And it will remain useful and important and fast for decades to come, certainly. But it’s not simple and hasn’t been for a long time. Let’s acknowledge that.
    - skohan 5y ago
      I'm sorry I don't understand your argument at all. What does lack of UB and memory safety have to do with simplicity? Those are very complex features of Rust which require a very complex compiler in order to achieve. Also Rust is notorious for having a steep learning curve, and it takes time for even very experienced programmers to become accustomed to it.