Untitled attachment

Got Stun Locked Again, so it's time to dump a rant I made elsewhere:

C is not a language for direct control of the hardware. C is a langauge that is coded to the semantics of an Abstract Machine specified in a document. It's no more capable of hardware control that e.g. Rust or Zig. What it has is a wide variety of pre-existing implementations that allow you to touch that hardware, but most of that control was programmed in an assembly language or worked into the hardware/firmware by somebody.

C is not more suitable for hardware and your computer is not a PDP-11. (This is part of why "Nobody writes ISO C" is a thing. C, the language K&R made, the language that got standardized, at any point in its lifetime, was never good enough for a kernel. It just let people coordinate stuff in the cheapest way possible and accepted extensions.)

The part that's extra nutso is that the last 20 years were people who held this exact belief -- that C was just a thin layer over the hardware -- get bodied, over and over again. Compiler vendors gave them the big middle finger every time they said "wait, no, UB is for hardware!", and compiler vendors traded in UB for (sometimes negligible) speed ups.

To still believe C is "for the hardware" in today's day and age where GCC will literally run your for loop for eternity because you tried to access an array out-of-bounds and it found out about it, or Clang will solve fermat's last theorem due to a loop, is magic shroom thinking. You can access the hardware just as good with Java by using the Pointer class, you can hit the same register that the shitty ISA Manual fucking lied about by writing the same integer address into the Pointer class and dumping out a 2-byte integer to the right place.

C is not magic and you're not improving its design by insisting it is, for the love of God start Evaluating Your Tools Properly. Yer an engineer, not a fucking wizard, Harry.

Public

Notices where this attachment appears