Hacker News Reader

Comment by hgs3 | Hacker News Reader

Not sure if you're aware, but defer is proposed for C2Y [1]. It's already available in Clang behind a compiler flag. It is interesting how the languages continue to diverge.

[1] https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3734.pdf

View on HN

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.

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.

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.

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.

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.

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.

Why should it be, the language doesn't expose any of it.

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.

I do certainly understand it, by the eyes of C++, Rust, Ada, Object Pascal, Modula-2, D.

Systems programming is not primarily about programming languages though...

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.

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.

Most of these methods and ideas turned out to not work, neither in messy C libraries, nor in C++ or other languages.

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

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++.

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?

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.

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

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.

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?

Ah, the "what is not standardized does not exist" argument again.

Why does the language standard need to prescribe everything. It is a standardization of between existing compilers, they are allowed and intended to invent things. If anything the experience from C++ has shown, that writing too much behaviour into the standard accidentally has consequences on the possible performance. The C standard is descriptive, not prescriptive.

> something that any programming language can offer in similar capacity?

By your measure a lot of other languages don't offer anything to begin with, because they do not have a standard at all, only a reference implementation.

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.

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

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

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.

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.

Yeah, a continuous memory model is used, because it is convenient, not because some old hardware happen to use it.

> 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.

Reply on news.ycombinator.com