They also point out that C is a bad first language. This shouldn't be relevant to many Computer Science courses, but I have seen too many Electronics students who are taught C first, or indeed as their only language.
Without understanding what code gets generated, there are so many footguns it can be dangerous at best. Knowing things like calling conventions and how the compiler interacts with memory are really important.
The assembler perspective is important, but not for correctness, rather for optimization. When you optimize it starts mattering how much register pressure and cache pressure etc you have.
Like I guess the point I have to make is that if you are writing C in 2024, there is likely a good reason, and if you don't know what's going on in the assembler, I feel like people are playing with fire.
I've found that I'm much less accurate when writing code for non-GCC/Clang compilers because my mental model of what's going to be generated isn't accurate enough without the years of experience I've had looking at the outputs of those specific compiler families.
(Although C++ wouldn’t be my first choice to begin with for a first language)
Someone who knows nothing would benefit from Pascal a lot even in 2023, even if the practical relevance of the language nowadays is nil (not due to lack of merit, but due to the social dynamics, as a commenter on the OP's original blog righly said) - by the way, R.I.P. Niklaus Wirth. I guess it would be a bit like studying Latin or classical Greek to learn about grammar.
Python is "conceptually worse" than Scheme and Pascal - for learners at an academic level, IMHO - but of course practically more useful/valuable, from an industry point of view.
For example you want fat pointers, particularly for slice types. On a PDP-11 spending two registers for these types is extravagant, today this seems ridiculous, but C still doesn't provide any fat pointer types. So either you have to roll your own (and with them libraries of code to use them) or put up with whatever was a good idea in the 1970s. The most famous slice type is Rust's &str or C++ std::string_view, a fat pointer for referring to text - strings in other words, but not the mutable, owned, auto-growing strings you might associate with higher level languages, this is just the simple concept of some text. C can't do that, what C gives you is a pointer to a byte, pointer arithmetic and a stern admonition to stop when you reach a byte with a zero value... or you can roll your own slice types.
I admit that I still have a soft spot for C; once I finally understood pointers I did most of my projects in C; it helped that I had (and still have) a love for systems programming. To this day I can write C in my sleep even though it's been two years since I've last written a significant amount of C. But in grad school I got bit hard by the Lisp and Smalltalk bugs....I went from a big Bell Labs fan to a Xerox PARC fan, and in my professional career I've been largely coding in Python for the past five years since it's now the lingua franca of machine learning.
But I wouldn't recommend C as a first language; I feel it's too much for absolute beginners. I'm torn between Python and Scheme; my feelings right now is that Python is a good introductory language for helping people gain programming experience and allowing students to build interesting things using Python's extensive libraries, while Scheme is an excellent vehicle for teaching how programming languages work at a high level; I have a soft spot for The Structure and Interpretation of Computer Programs (this was the introductory CS textbook at MIT from the 1980s to the late 2000s when MIT switched to Python) and I used it as part of an upper-division course on programming language principles and paradigms at a university where Java is the introductory language.
You can read about how experts write their C code (like https://nullprogram.com/blog/2023/10/08/) but you aren't going to appreciate why they decide to do this. Indeed, beginners need to be able to blindly follow rules before they can critique them or invent their own coding styles.
typedef struct { i32 value; b32 ok; } i32parsed;
Defined a Result Type.
The biggest problem with C is that it lets you do anything to include things you don't want to do and should not do.
"The programmer knows best" means you can easily write to arbitrary memory addresses, smash the call stack, allocate memory and never free it, etc. and as long as the syntax is correct, your program will compile.
Sometimes, in interesting low-level code, embedded code, or similar, this unrestricted behavior is needed: you write seemingly arbitrary values to a memory address because it is memory-mapped hardware and that is where the control register receives instructions. But in most application-level code, it is bad behavior and just causes segment violations.
"The programmer knows best" is the primary cause of security flaws in C (and C++ because of its heavy compatibility with C) since even experienced C programmers make mistakes or find their code being used in unanticipated ways.
It's great if you're coming from assembly language and the de-factor standard for embedded systems.