🦊 welcome to the vulpe zone 🦊

🔮 adult furry artist and programmer 🔮

be advised some of the posts here might be nsfw! for now most of them will sfw be though.

ive posted a few game titles to itch now! feel free to check em out!
i sure am gonna miss this place
https://foxball.carrd.co/


ThePhD
@ThePhD

But boy howdy even if I can't shitpost good I can ABSOLUTELY FUCKING RANT GOOD so here's one more thing I got Stun Locked on after reading a sea of dogshit takes under somebody else's tweet about C and C++.

C is not a language for direct control of the hardware.

C is a language 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 preexisting 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?

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. The idea of "hardware" disappeared entirely.

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 an infinite loop inside of a function, is magic shroom thinking. You can access the hardware just as good with Java, 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.


You must log in to comment.

in reply to @ThePhD's post:

Back when I used to teach a programming languages course, I used to make the biggest deal about separating historical patterns of use with what a language "is for." I would go through pretty much the same reasoning on C, but also make the point that, if C is "a hardware language" for resembling the PDP series, then LISP is even more of one for its resemblance to the IBM 704's architecture, CAR and CDR being instructions to get the Contents of the Address/Decrement Register...

This is very much the truth of the situation. Historical and even contemporary use cases don't necessarily define the language, and ascribing those use cases to the language rather than spending time to sit down and say "what were the tradeoffs and circumstances and decisions around this that produced these effects, and what can we control?" is what results in people making things and then being confused as to why it doesn't have the same impacts!

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. The idea of "hardware" disappeared entirely.

!!!!! ty yesssss

Would it be fair to say that C is a language about manipulation of a """hardware"""-like (PDP-11-like) abstract machine, i.e. C is a language that describes (abstract) hardware manipulation? Which does not imply that C is good fit for hardware manipulation problems, but does imply that C is a bad fit for problems not about hardware manipulation.