Great article --- very little having to do with C though.
It might be unpopular to say this but: can we please stop teaching people to write new programs in C? The language is inherently unsafe, and we're collectively losing billions of dollars per year to preventable memory safety errors.
Why not use Rust or C# or something to demonstrate the principles of hash tables? Why start with the programming equivalent of a 1950s death crap automobile with a spike in the center of the steering wheel?
Driving without power steering has made my arms much stronger, and a giant spike capable of ramming through my lungs at collision has made me a much safer driver. I can also repair a 1950s mobile, because it’s mechanical workings are much simpler than something modern
No, we can’t. Because C is a necessary evil. If you stop teaching people to program in C, who is going to maintain virtually every software this world is running on?
Presumably the same way find all of the people who maintain all of the critical software written in Fortran or COBOL or Ada or other languages that aren't really taught in schools anymore.
If a new hire is minimally competent at programming, I can bring them up to speed in whatever language it is we are using. Hell, even when people have notionally been taught a language in school, there's a decent chance I would still have to train them in that language as a new hire, because what they learned in school may be insufficient to cover the complexities that get involved in practice.
And to OP's point: C itself is a pretty poor language at covering what it actually covers. It has some missing features that just seem random (e.g., there are no 8- or 16-bit arithmetic operators in C). It has gratuitous undefined behavior (signed integer overflow and strict aliasing). As a language design, it's atrociously outdated (#include is a very poor substitute for modules, and generic programming might as well not exist in C). There are questionable features--null-terminated strings don't look like such a good idea in retrospect. Even if you want to avail yourself of its strengths--access to low-level hardware features--C's gratuitous undefined behavior (particularly strict aliasing) undercut it there, and languages like Rust and Zig give you the same power with none of C's warts.
> C itself is a pretty poor language at covering what it actually covers.
C's job is to be the first thing ported to a new architecture, allow you to bootstrap a system, and build on top of it (last 2 steps optional if you're working on some sort of embedded system).
And, frankly, it's reasonably good at that. Writing a simple C compiler is trivial compared to something like rust.
Out in embedded land, where you will have C, assembler and a tiny library if you are lucky, the luxuries of Rust just aren't widely available yet. Its also a very valuable language to learn since the big 3 operating systems are made out of it. You can't wish that away.
Out of curiosity, what kind of embedded device has only C and asm support? Usually, the compiler used for these is gcc which, for a really long time is written in C++. It shouldn't be hard to use even go on embedded now. Also Rust gets rustc_codegen_gcc[1], so you will be able to use it everywhere.
Sometimes the compiler is gcc, but the libraries are...some weird hybrid. Texas Instruments RTOS used their own compiler and a strange mashup of C/C++ (xdctools they call it). I don't understand it, it kind of looks like if somebody had been described the original cfront over the telephone. The latest versions are undoing some of that and they even have the option of using a clang compiler, but on their older chips you are stuck with the original weirdness, which basically means you are restricted to C and assembly in a practical sense.
Oh hell no. There are some useful uses of hashing in them though, such as verifying the contents of flash memory before loading it. I was recommended Murmer[0] and use it as a kind of "is what is contained in the flash memory consistent with what was written" check for an app that has to keep some state between reboots. You could use it in an embedded device for a hash table but it's probably faster to make a b-tree or just brute force an array.
It might be unpopular to say this but: can we please stop teaching people to write new programs in C? The language is inherently unsafe, and we're collectively losing billions of dollars per year to preventable memory safety errors.
Why not use Rust or C# or something to demonstrate the principles of hash tables? Why start with the programming equivalent of a 1950s death crap automobile with a spike in the center of the steering wheel?