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.

▲

gritzko 7 hours ago | parent | next [-]

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

▲

pjmlp 7 hours ago | parent [-]

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 6 hours ago | parent | next [-]

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?

▲

pjmlp 2 hours ago | parent | next [-]

It is, however hardly something unique to C, as the C crowd pretends it to be.

▲

shakna 6 hours ago | parent | prev [-]

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 6 hours ago | parent [-]

IIRC PDP-11 was a 16 bit word machine with an 8-bit byte. Maybe you remember PDP-10 with 4x9=36 bit words?

▲

zabzonk 19 minutes ago | parent | next [-]

Actually, if you were mad enough to use the feature, the Dec10 had 6-bit "bytes" - 6 to a word.

▲

uecker 5 hours ago | parent | prev | next [-]

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.

▲

pjmlp an hour ago | parent [-]

So when is WG14 standardising modern hardware into the C standard?

Basic stuff like SIMD, SIMT, without requiring users to go beyond language extensions, something that any programming language can offer in similar capacity?

	▲	uecker 11 minutes ago \| parent [-]
		Ah, the "what is not standardized does not exist" argument again.

▲

shakna 3 hours ago | parent | prev [-]

On the 11, the UNIBUS was 18 bit, the program space was 16 bit, and addressing was 22 bit. So it depended if you were using I-space or D-space.

▲

flohofwoe 4 hours ago | parent | prev [-]

The PDP-11 myth is getting a bit tired by now ;)

If C would be so hardwired to the PDP-11 architecture it would have died with it. In reality C works just fine on all sorts of hardware (like GPUs) with only minor extensions.

	▲	pjmlp 2 hours ago \| parent [-]
		Just like plenty of other programming languages. I am also tired that language extensions in C to work around ISO defencies is considered an advantage when argued by C folks, while at the same time it is considered a language design fault when the same crowd points to other programming languages.

▲

jstimpfle 8 hours ago | parent | prev [-]

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 7 hours ago | parent [-]

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 7 hours ago | parent [-]

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 7 hours ago | parent [-]

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 6 hours ago | parent | next [-]

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 2 hours ago \| parent [-]
		Why should it be, the language doesn't expose any of it.

▲

jstimpfle 6 hours ago | parent | prev [-]

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.

▲

pjmlp 2 hours ago | parent [-]

So abstractions are desired then?

I have seen plenty of self inflicted complexity in C, starting in the golden age of Yourdon Structured Method, and all those libraries that replicate C++ basic features with preprocessor macros.

	▲	jstimpfle an hour ago \| parent [-]
		Most of these methods and ideas turned out to not work, neither in messy C libraries, nor in C++ or other languages.