Is learning C really a must for a programmer?

Many have this opinion. Somehow, by doing manual memory management allocation and garbage mangement one would become a better programmer.

I have little experience in C mainly because I can write terser and more readable code in Racket or Haskell. However I'm willing to give C a try just to learn these lessons that everybody keeps talking.

But I have a sneaking suspicion that I already know most of what is there to know. Can you list some useful lessons that a typical high level code dweller would be oblivious of?

>>55
Using only static allocation with (or without) the stack is very common in memory constrained environments, as it ensures that memory usage will never grow past a hard limit or become fragmented. As an example, the Mars Curiosity Rover was developed according to the JPL C coding standards, part of which includes basically forbidding dynamic memory allocation in order to eliminate allocation failure-related bugs.

A common tool used in these environments is a "memory pool", basically a statically allocated chunk of memory that you can allocate and destroy (usually) fixed-size objects within. Consider a program that needs to allocate and destroy hundreds of tiny objects per second, at unpredictable intervals. Rather than using standard malloc/free and fragmenting the fuck out of your memory (similar to the situation on a disk, memory fragmentation can quickly lead to a situation where you have enough memory available to allocate something, but because there aren't any contiguous free regions large enough, the allocation fails), you statically allocate ("set aside") enough space for a few hundred of those objects and let a memory pool library handle allocations within the pool.

>>56's quote makes it sound like a ridiculous practice ("who would write their own memory allocator for a typesetting program?"), and iirc even Knuth regrets some of the technical decisions he made when developing TeX, but I'm sure it made more than enough sense back in 1978.