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

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

#181

Post by direwolf20 » Sat, Feb 07, 2026, 8:46 AM UTC

1718627440 wrote: post #172

direwolf20 wrote: post #169

Earlier quoted context omitted.

I'm not writing the app. The app was written according to your preferred design and I'm compiling it for Arduino. You say to just use int because it always has enough bits, then you say to sometimes use long because int might not have enough bits.

There is a platform where int has less than the prescribed 16 bits? How much does it have then, just 8bit or something weird?

Arduino has 16-bit int, so the timer app will work up to 32.767 or 65.535 seconds, that is less than two minutes.

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

#182

Post by direwolf20 » Sat, Feb 07, 2026, 8:47 AM UTC

donkeybeer wrote: post #125

direwolf20 wrote: post #122

Earlier quoted context omitted.

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.

So you've backtracked from most variables, to number of elements.

For number of elements there's size_t. So again, when are "natural types" the right answer?

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

#183

Post by direwolf20 » Sat, Feb 07, 2026, 8:48 AM UTC

1718627440 wrote: post #168

direwolf20 wrote: post #123

Earlier quoted context omitted.

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

Then you use an integer type that has at 32-bits? uint32_fast_t for computation, uint32_least_t for storage, if you are resource constrained.

This is never not the case. You always need to specify the number of bits.

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

#184

Post by direwolf20 » Sat, Feb 07, 2026, 8:48 AM UTC

donkeybeer wrote: post #125

direwolf20 wrote: post #122

Earlier quoted context omitted.

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.

The length of a type is always a hard requirement.

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

#185

Post by jcgl » Sat, Feb 07, 2026, 8:54 AM UTC

uecker wrote: post #68

ChrisSD wrote: post #52

Earlier quoted context omitted.

It minimally reflects PDP-11 assembly, which is not how modern computers work.

This is a meme which is repeated often, but not really true. If you disagree, please state specifically what property of PDP-11 you think it different from how modern computers work, and where this affects C but not other languages.

This isn’t my space to opine on, but I found this talk both riveting and compelling: https://m.youtube.com/watch?v=36myc8wQhLo&t=1s&pp=2AEBkAIB

In a nutshell, the useful fiction of computer-as-Von-Neumann-meaning doesn’t adequately reflect the reality of modern hardware. Not only does the CPU itself not fit that model (with things like speculative execution, sophisticated power and load management…), but the system as a whole is increasingly an amalgamation of different processors and address spaces.

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

#186

Post by Gibbon1 » Sat, Feb 07, 2026, 10:00 AM UTC

AnimalMuppet wrote: post #41

munificent wrote: post #20

Earlier quoted context omitted.

I'm not sure what you mean by "coincidence" or "accident" here. C is a pretty OK language for writing an OS in the 70s. UNIX got popular for reasons I think largely orthogonal to being written in C. UNIX was one of the first operating systems that was widely licensed to universities. Students were obliged to learn C to work with it. If the Macintosh OS had come out first and taken over the world, we'd probably all be…

Repeating a previous comment of mine ( https://news.ycombinator.com/item?id=32784959 ) about an article in Byte Magazine (August 1983) on the C programming language: From page 52: > Operating systems have to deal with some very unusual objects and events: interrupts; memory maps; apparent locations in memory that really represent devices, hardware traps and faults; and I/O controllers. It is unlikely that even a low-…

I've started describing what C does is breaking the third wall. Which in theater sis when the actors acknowledge they're in a play.

C totally accepts breaking the third wall. And Pascal doesn't.

Problem with C currently is the language is controlled by people that think programming languages should be like Pascal.

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

#187

Post by cornhole » Sat, Feb 07, 2026, 10:07 AM UTC

hacker_homie wrote: post #55

It's not that it was made this way to annoy you, it was all we had. The whole world shouldn't "need to be fixed" because you won't spend the time to learn something. Rust doesn't even have a stable Internal ABI that's why you have to re-compile everything all the time.

doesn’t mean it can’t be improved, but also doesn’t guarantee that the new way isn’t some sort of brand new hell

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

#188

Post by 1718627440 » Sat, Feb 07, 2026, 10:29 AM UTC

direwolf20 wrote: post #181

1718627440 wrote: post #172

Earlier quoted context omitted.

There is a platform where int has less than the prescribed 16 bits? How much does it have then, just 8bit or something weird?

Arduino has 16-bit int, so the timer app will work up to 32.767 or 65.535 seconds, that is less than two minutes.

When you choose unsigned int for that type, you compare against UINT_MAX and return an EOVERFLOW, ENOMEM, EOUT_OF_RANGE or whatever you like when someone sets a timer greater than that. Or you choose another type, i.e. unsigned long which is guaranteed to take values to at least 4294967295. I happen to program for the Arduino platform recently and milliseconds in the Arduino API are typed unsigned long.

If your decision is that you really want to store all 32-bit values then you use uint_least32_t or uint_fast32_t depending if you are also resource constrained.

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

#189

Post by donkeybeer » Sat, Feb 07, 2026, 10:38 AM UTC

direwolf20 wrote: post #182

donkeybeer wrote: post #125

Earlier quoted context omitted.

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.

So you've backtracked from most variables, to number of elements. For number of elements there's size_t. So again, when are "natural types" the right answer?

When the C was invented? I feel it'd have been much more burdensome and inhibited the authors of various compilers if they had to write software or otherwise emulation of all these lenghths on the archs of the time. Still today I'd say, you cited size_t, I think that's the most important type, otherwise we shouldn't make most uses of integers as named fixed lengths unless we are specifically performing some mathematical operation like finite field arithmetic where the bit length matters or as you noted you know your problem size might be large enough that some archs machine words are too small. Otherwise I don't see why we shouldn't just default to natural lengths. Otherwise we need to write different int types for each arch and that doesn't sound nice unless we explicitly see a reason to.

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

#190

Post by donkeybeer » Sat, Feb 07, 2026, 10:46 AM UTC

direwolf20 wrote: post #182

donkeybeer wrote: post #125

Earlier quoted context omitted.

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.

So you've backtracked from most variables, to number of elements. For number of elements there's size_t. So again, when are "natural types" the right answer?

Tbh I am finding it a bit hard to think of a use of integers that either isn't a length or a mathematical operation, so I gotta say it does narrow things down.