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?

>>66
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.
This is still dynamic allocation. You might even unknowingly have used a malloc implementation that had a static limit. When the pool is empty you've got an error. Static memory allocation means that all computations are bounded in space. There's no recursion and no variable sized objects (where do you store references to the fixed-size object, in another fixed-size object?). This works fine for a lot of data crunshing where you can work with an independent subset at a time and applications where the dimension of data vectors in the domain are obviously smaller than an suitably chosen number. Sometimes it's also okay to truncate strings that are too long.

Creating your own tailor made custom allocator that returns (usually) fixed-size ranges from a static word_t pool[POOL_SIZE]; doesn't mean you're suddenly allocating objects statically. Yes, you've gotten rid of fragmentation since your allocator knows that every allocation is equally big, and that's an advantage  malloc doesn't have. Who'd have thought that optimizing for the special case wins over a general case implementation?

I know, let's all just allocate cons pairs (they're fixed size) and then we can build arbitrarily long vectors and strings by chaining them togehter. It's all statically allocated!