C isn't a programming language anymore (2022) • Hacker News Board

Re: C isn't a programming language anymore (2022)

#121

Post by direwolf20 » Fri, Feb 06, 2026, 12:34 PM UTC

ghosty141 wrote: post #94

kristianp wrote: post #64

Earlier quoted context omitted.

It seems to be a meme on HN that C doesn't reflect hardware, now you're extending that to assembly. It seems silly to me. It was always an approximation of what happens under the hood, but I think the concepts of pointers, variable sizes and memory layout of structs all represent the machine at some level.

Its not a meme. For example, C has pointer provenance, so pointers arent just addresses. Thats why type punning is such a mess. If a lang claims to be super close to the hardware this seems like a very weird thing.

It remains close to computer hardware + optimiser. This provenance thing was introduced to aid optimisation.

Re: C isn't a programming language anymore (2022)

#122

Post by direwolf20 » Fri, Feb 06, 2026, 12:36 PM UTC

donkeybeer wrote: post #104

smallstepforman wrote: post #61

C’s biggest sins (also inherited by C++): - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning. - aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword. T…

Which systems in the 70s or even 90s would have had good hardware support for all these lengths? I think overall perhaps its better that the thing named int works on both the arduino and my amd64 otherwise we might needlessly need to rename all types for each platform to fit the most natural type lengths there. Imagine the 32 bit to 64 bit transition under those conditions.

But it doesn't work. You use an int to hold milliseconds, it works on your machine, and when compiled for Arduino (16–bit int) it wraps around every minute.

Re: C isn't a programming language anymore (2022)

#123

Post by direwolf20 » Fri, Feb 06, 2026, 12:37 PM UTC

1718627440 wrote: post #103

smallstepforman wrote: post #61

C’s biggest sins (also inherited by C++): - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning. - aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword. T…

> - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning. I strongly disagree. The programmer should rather prescribe intent and shouldn't constantly think about what size this should exactly have. Does this variable represent the size of an object, an address, a difference or just a random positive integer? Then use size_t, uintptr_t, ptrdiff_t and unsigned int respectively.…

Your problem demands a certain number of bits. Counting milliseconds in a month needs 32 bits. It's not just a random number.

Re: C isn't a programming language anymore (2022)

#124

Post by direwolf20 » Fri, Feb 06, 2026, 12:38 PM UTC

donkeybeer wrote: post #114

danhau wrote: post #108

Earlier quoted context omitted.

How will you know if your integer type is adequate for the problem at hand, if you don‘t know its size? Choosing the right type is a function of signedness, upper/lower bound (number of things), and sometimes alignment. These are fundamental properties of the problem domain. Guesstimating is simply not doing the required work.

The idea is mostly that we shouldn't worry. The user of the lib on an arduino will feed it arduino sized problems and the amd64 user will likewise larger problems. Again I think just think of the transition from 32 to 64 bit. Most ranges are "input"/"user " dependent and it would have been needlessly messy to have to even with automatic conversion help rewrite say every i32 to i64 or which ones to convert.

That's size_t. What about counting milliseconds?

Re: C isn't a programming language anymore (2022)

#125

Post by donkeybeer » Fri, Feb 06, 2026, 12:39 PM UTC

direwolf20 wrote: post #122

donkeybeer wrote: post #104

Earlier quoted context omitted.

Which systems in the 70s or even 90s would have had good hardware support for all these lengths? I think overall perhaps its better that the thing named int works on both the arduino and my amd64 otherwise we might needlessly need to rename all types for each platform to fit the most natural type lengths there. Imagine the 32 bit to 64 bit transition under those conditions.

But it doesn't work. You use an int to hold milliseconds, it works on your machine, and when compiled for Arduino (16–bit int) it wraps around every minute.

We have stdint in modern systems so when the length of a type is a hard requirement then we can use whatever type or software emulate a larger word. Otherwise I think keeping the default types for things like eg number of elements seems alright.

Re: C isn't a programming language anymore (2022)

#126

Post by direwolf20 » Fri, Feb 06, 2026, 12:39 PM UTC

pjmlp wrote: post #92

SanjayMehta wrote: post #24

Earlier quoted context omitted.

VHDL vs Verilog is a good parallel from the chip world. VHDL was designed from ground up. Verilog is loosely based on C. Most designs are done in Verilog.

VHDL tends to reign in European hardware companies.

I wonder why there aren't many successful European hardware products.

Re: C isn't a programming language anymore (2022)

#127

Post by donkeybeer » Fri, Feb 06, 2026, 12:41 PM UTC

direwolf20 wrote: post #124

donkeybeer wrote: post #114

Earlier quoted context omitted.

The idea is mostly that we shouldn't worry. The user of the lib on an arduino will feed it arduino sized problems and the amd64 user will likewise larger problems. Again I think just think of the transition from 32 to 64 bit. Most ranges are "input"/"user " dependent and it would have been needlessly messy to have to even with automatic conversion help rewrite say every i32 to i64 or which ones to convert.

That's size_t. What about counting milliseconds?

As I said, today when it really matters we can use stdint. But I feel it would have been too burdensome to mandate on the standard in the early days of C.

Re: C isn't a programming language anymore (2022)

#128

Post by anthk » Fri, Feb 06, 2026, 12:44 PM UTC

C under Plan9 it's pretty easy to understand. Under current BSD's and worse... GNUs, it's a nightmare.

With C++ it's the same. Within the Haiku code it's half understandable, the whole spec it's to get driven mad in days.

Re: C isn't a programming language anymore (2022)

#129

Post by pjmlp » Fri, Feb 06, 2026, 12:47 PM UTC

direwolf20 wrote: post #126

pjmlp wrote: post #92

Earlier quoted context omitted.

VHDL tends to reign in European hardware companies.

I wonder why there aren't many successful European hardware products.

I would assert any company that doesn't go bankrupt is successful, doesn't need to be late stage capitalism.

Other than that, Nokia until Microsoft placed an agent on it, Phillips that contributed to CDs, ASML...

Re: C isn't a programming language anymore (2022)

#130

Post by therealcamino » Fri, Feb 06, 2026, 12:47 PM UTC

SanjayMehta wrote: post #24

mjg59 wrote: post #19

I really don't understand why people keep misunderstanding this post so badly. It's not a complaint about C as a programming language. It's a complaint that, due to so much infrastructure being implemented in C, anyone who wants to interact with that infrastructure is forced to deal with some of the constraints of C. C has moved beyond merely being a programming language and become the most common interface for in-pr…

VHDL vs Verilog is a good parallel from the chip world. VHDL was designed from ground up. Verilog is loosely based on C. Most designs are done in Verilog.

Well, VHDL was heavily based on Ada.