3 ms·

Because the communities aren't the same. C++ is 1990's Typescript for C++, while C folks still think is a portable Assembly instead of designed to an abstract

by pjmlp 6mo ago

Because the communities aren't the same. C++ is 1990's Typescript for C++, while C folks still think is a portable Assembly instead of designed to an abstract machine model. As such C++ community embraces high level abstractions and type systems improvements, whereas C wants to still code as targeting classical hardware.

jstimpfle 6mo ago
Caring for the actual assembler output in selected critical pieces of code is not the same as ignoring the abstract machine model. What you claim is simply not the case if you check actual proficient systems programmers. Of which there are an astonishingly high share C and C++-but-mostly-C programmers.
- pjmlp 6mo ago
  Any user of compiled languages cares about Assembly, which is why regardless of the compiled language, an Assembler was always shipped alongside. Also it isn't a C invention to have the compiler dump the Assembly output instead of object code. Now the culture that C language constructs in 2026 are still 1:1 to Assembly instructions, that pretty much prevails, despite easy proof that isn't the case at various compiler optimization levels. Proficient devs, well many still don't know to distinguish what is their compiler, and what ISO says.
  - jstimpfle 6mo ago
    It is the case that you can more easily know what happens when you don't use the wrong abstractions but stay in control. Highly-abstracted C++ code basically makes allocations and syscalls in the whitespace between the source code tokens. You can't do systems software like that, you have to roll back the abstractions and roll back the use of pre-canned containers and libraries that you don't understand. So it's all about understanding and control, not about some idea that C was defined in terms of assembly instructions, which it obviously is not. That's a total strawman.
    - pjmlp 6mo ago
      Except modern C also has plenty of abstractions, devs wrongly assume it doesn't. Then get surprised when it doesn't map to the SIMD/SIMT NUMA machine their code actually executes on.
      - uecker 6mo ago
        There is not much real evidence for "devs wrongly assume" and as someone writing numerical code (clusters, NUMA, SIMD, etc.) I think C is still the ideal tool for this.
        pjmlp 6mo ago
        Why should it be, the language doesn't expose any of it.
        uecker 6mo ago
        Assuming you mean the standard does not provide features for numa and simd? It doesn't necessarily have to. I think it is not surprising that you seem always bewildered that people still use C (as per your comments), as it seems you fundamentally do understand neither standardization nor systems programming.
        pjmlp 6mo ago
        I do certainly understand it, by the eyes of C++, Rust, Ada, Object Pascal, Modula-2, D.
        jstimpfle 6mo ago
        Systems programming is not primarily about programming languages though...
      - jstimpfle 6mo ago
        such a strawman again... You don't want to be writing explicit platform specific SIMD most of the time. You just want to write a dumb function that doesn't do any non-obvious calls, doesn't cause thread contention, doesn't hide complexity, isn't going to be a nightmare to change later, no surprises. I am talking about self-inflicted complexity that is entirely within the C(++) machine model. Avoid that complexity and you're pretty good already. Only drop down to concrete hardware arch level where it makes sense. But largely, the C machine model is still very much suited as a model for actual hardware. Writing straightforward obvious code allows you to stay in control of memory layout and the data transformation paths. It easily gets you within <<2x of what you could achieve with hand coded assembler for the >90% of the code that are pretty boring and straightforward. And obviously you couldn't get the work done in time when coding everything in assembler.
gritzko 6mo ago
That is the entire point, yes. Reasoning about layers of completely imaginary entities is what demotivates me about C++ and Rust. Meanwhile, hardware bits are very real (and getting more expensive recently). Having implemented slices and generics in C, now C++ feels like Vietnam flashbacks. https://replicated.wiki/blog/abc https://replicated.wiki/blog/abc
- pjmlp 6mo ago
  Yet C23 isn't K&R C any longer, nor is the hardware a PDP 11. Also when we eventually start talking to agents that perform the whole execution steps by themselves, that is kind of irrelevant. Except for the lucky ones that still code to keep the infrastructure going, which is mostly C++.
  - uecker 6mo ago
    The "nor is the hardware a PDP 11". Byte access was the main new feature of the PDP 11 that C adopted. Are you saying being able to access individual bytes is not relevant on modern hardware?
    - shakna 6mo ago
      Might more mean that we've standardised on a few things like what a byte even is. The PDP-11 had both 8 and 9-bit bytes. Thats a complexity that few programmers have to touch on, today.
      - elch 6mo ago
        IIRC PDP-11 was a 16 bit word machine with an 8-bit byte. Maybe you remember PDP-10 with 4x9=36 bit words?
        uecker 6mo ago
        Anyway, I do not see how this affects the design of C in a way that makes no sense anymore today (except that one could require CHAR_BIT to be eight, but there are still DSPs where this is not the case). I think people repeat the "the C design reflects the out-dated PDP-11 hardware" meme because it sounds smart while in reality it is just nonsense.
wasmperson 6mo ago
> C folks still think is a portable Assembly > C [community] wants to still code > many still don't know to distinguish > the culture that... despite easy proof that isn't the case > devs wrongly assume > self inflicted complexity > considered an advantage when argued by C folks > when the same crowd points > as the C crowd pretends it to be You're arguing in this thread not by addressing what people are actually saying but by bringing up some hypothetical version of what "the C Community" thinks, then arguing with that.

by pjmlp 6mo ago

jstimpfle 6mo ago

Caring for the actual assembler output in selected critical pieces of code is not the same as ignoring the abstract machine model. What you claim is simply not the case if you check actual proficient systems programmers. Of which there are an astonishingly high share C and C++-but-mostly-C programmers.

pjmlp 6mo ago
Any user of compiled languages cares about Assembly, which is why regardless of the compiled language, an Assembler was always shipped alongside. Also it isn't a C invention to have the compiler dump the Assembly output instead of object code. Now the culture that C language constructs in 2026 are still 1:1 to Assembly instructions, that pretty much prevails, despite easy proof that isn't the case at various compiler optimization levels. Proficient devs, well many still don't know to distinguish what is their compiler, and what ISO says.
- jstimpfle 6mo ago
  It is the case that you can more easily know what happens when you don't use the wrong abstractions but stay in control. Highly-abstracted C++ code basically makes allocations and syscalls in the whitespace between the source code tokens. You can't do systems software like that, you have to roll back the abstractions and roll back the use of pre-canned containers and libraries that you don't understand. So it's all about understanding and control, not about some idea that C was defined in terms of assembly instructions, which it obviously is not. That's a total strawman.
  - pjmlp 6mo ago
    Except modern C also has plenty of abstractions, devs wrongly assume it doesn't. Then get surprised when it doesn't map to the SIMD/SIMT NUMA machine their code actually executes on.
    - uecker 6mo ago
      There is not much real evidence for "devs wrongly assume" and as someone writing numerical code (clusters, NUMA, SIMD, etc.) I think C is still the ideal tool for this.
      - pjmlp 6mo ago
        Why should it be, the language doesn't expose any of it.
        uecker 6mo ago
        Assuming you mean the standard does not provide features for numa and simd? It doesn't necessarily have to. I think it is not surprising that you seem always bewildered that people still use C (as per your comments), as it seems you fundamentally do understand neither standardization nor systems programming.
        pjmlp 6mo ago
        I do certainly understand it, by the eyes of C++, Rust, Ada, Object Pascal, Modula-2, D.
        jstimpfle 6mo ago
        Systems programming is not primarily about programming languages though...
    - jstimpfle 6mo ago
      such a strawman again... You don't want to be writing explicit platform specific SIMD most of the time. You just want to write a dumb function that doesn't do any non-obvious calls, doesn't cause thread contention, doesn't hide complexity, isn't going to be a nightmare to change later, no surprises. I am talking about self-inflicted complexity that is entirely within the C(++) machine model. Avoid that complexity and you're pretty good already. Only drop down to concrete hardware arch level where it makes sense. But largely, the C machine model is still very much suited as a model for actual hardware. Writing straightforward obvious code allows you to stay in control of memory layout and the data transformation paths. It easily gets you within <<2x of what you could achieve with hand coded assembler for the >90% of the code that are pretty boring and straightforward. And obviously you couldn't get the work done in time when coding everything in assembler.

gritzko 6mo ago

That is the entire point, yes. Reasoning about layers of completely imaginary entities is what demotivates me about C++ and Rust. Meanwhile, hardware bits are very real (and getting more expensive recently). Having implemented slices and generics in C, now C++ feels like Vietnam flashbacks. https://replicated.wiki/blog/abc https://replicated.wiki/blog/abc

pjmlp 6mo ago
Yet C23 isn't K&R C any longer, nor is the hardware a PDP 11. Also when we eventually start talking to agents that perform the whole execution steps by themselves, that is kind of irrelevant. Except for the lucky ones that still code to keep the infrastructure going, which is mostly C++.
- uecker 6mo ago
  The "nor is the hardware a PDP 11". Byte access was the main new feature of the PDP 11 that C adopted. Are you saying being able to access individual bytes is not relevant on modern hardware?
  - shakna 6mo ago
    Might more mean that we've standardised on a few things like what a byte even is. The PDP-11 had both 8 and 9-bit bytes. Thats a complexity that few programmers have to touch on, today.
    - elch 6mo ago
      IIRC PDP-11 was a 16 bit word machine with an 8-bit byte. Maybe you remember PDP-10 with 4x9=36 bit words?
      - uecker 6mo ago
        Anyway, I do not see how this affects the design of C in a way that makes no sense anymore today (except that one could require CHAR_BIT to be eight, but there are still DSPs where this is not the case). I think people repeat the "the C design reflects the out-dated PDP-11 hardware" meme because it sounds smart while in reality it is just nonsense.

wasmperson 6mo ago

> C folks still think is a portable Assembly > C [community] wants to still code > many still don't know to distinguish > the culture that... despite easy proof that isn't the case > devs wrongly assume > self inflicted complexity > considered an advantage when argued by C folks > when the same crowd points > as the C crowd pretends it to be You're arguing in this thread not by addressing what people are actually saying but by bringing up some hypothetical version of what "the C Community" thinks, then arguing with that.