The biggest (perhaps the only) way that C was actually ahead of its time was its support for "functional" programming: pass-by-value, higher-order functions,[1] macros[2] and even having functions at all.[3]
[1] 40 years before Java, and before any other mainstream non-Lisp.[1b]
[1b] Algol 68 supported function pointers first, but it was, famously, too ahead-of-its-time to implement. Pascal had limited support for function parameters but didn't support returning them or specifying their parameter types or arity.
[2] An advanced feature for the time.
[3] Fortran, Cobol, PL/I, etc still only supported procedures, which were themselves considered a somewhat advanced feature at the time.
To be a bit of a quibbler, a dynamic array is almost always going to be faster than a linked list, especially when N is small, and unless you're writing C (or, for somewhat different reasons, a FP lang) the code will be simpler too.
But of course, with small Ns, outside of the tightest of inner loops or the most resource-constrained embedded targets, most any halfway-reasonable data structure is going to be (and has been for 20+ years) easily fast enough. So it is a bit of a tomato tomahto thing.
Nope, you're assuming that you're allocating in order to create the list. That's not always the case! :) It's very common in games and embedded systems to have the nodes in memory, pre-allocated, pre-loaded, baked into executable or game data, etc. If space for list pointers is baked in advance, you can use linked lists without the separate allocation costs of a dynamic array or other container class.
Also, a dynamic array can be slower than a linked list because you realloc larger chunks than 1 node. You pay larger costs for larger allocations, and it can also cause more fragmentation in a custom size-pooled allocator.
It's also common to forget that a dynamic array of pointers is two allocations per node (one of them potentially amortized... except for small N). It's a single allocation if you're storing the node struct directly in the array. But that's less common than people creating a dynamic array of pointers.
I guess I'm an outlier-- while I have read misleading/wrong comments in C code, I can't think of a single time where I've had my time significantly wasted by a misleading comment in C code.
I can think of several times where I've been slapped by a wrongly named function. Oops, turns out "check_width" doesn't merely return an int but instead mutates something deep in the bowels of the program.
This is my favorite sentence. He's hinting at functional programming!
> I tend to err on the side of eliminating comments. [...] A misleading comment can be very confusing.
I can't even keep track of how many times I've tried to read code and comments I wrote from more than 6 months ago, and thought to myself "this doesn't make sense" or "how can this possibly work?" Or "this is impenetrable, I wish the idiot who wrote this would have used a little self-constraint and tried to simplify rather than show off and make everything complicated."
I'm getting more and more aware every year of how insanely hard it is to write or say things that are both clear and unambiguous. Every time I think I'm being clear and unambiguous, I find out later I was neither by a mile.
> Fancy algorithms are slow when n is small, and n is usually small.
I learned this fairly well working in games, where it's frequently faster to do a linear search or to use a linked list. The really basic stuff I was taught to avoid in school. But even now I have a hard time not using a hash table or tree or something at first, even when I know the data set will probably be small.