I'm deeply conflicted about this article because I agree with many of its premises. For instance: that C is superior to full-blown C++, that object-oriented pro

I'm deeply conflicted about this article because I agree with many of its premises. For instance: that C is superior to full-blown C++, that object-oriented programming is no panacea, that simplicity is good. I have serious concerns, however, especially with the first page and the first few chapters. - They support the biases of the myopic programmer who believes that now he or she knows C, they know everything one must know about programming. I know that isn't the entire point, but you can get that from the article and I have met such programmers. You don't want to work with them, even on projects written in C. - The "C Craft" section largely describes hacks to work around shortcomings in the syntax or semantics of C. - The languages used for "vs" comparison are: FORTRAN, C++, Java. Fish in a barrel, anyone? Haskell, APL & J are presented as curios. Python is only mentioned in passing, as an inferior choice to Haskell for rapid prototyping of mathematically-oriented code. - Go is presented as the "better C", which is encouraging but I'd feel more encouraged if the author showed they were properly familiar with some additional modern programming languages and the cases in which one might use them. - The assertion that "you can write object-oriented code in C" is accurate, although I think a better point to stress is "you can write mostly-well-modularised code in C, and that's what you want a lot of the time." - The author also ignores the reality that object-oriented C really only scales up to a certain amount of object-orientatedness, and then it becomes very unwieldly if you are not very careful. Unwieldy at a scale where using a small subset of C++ (ie "C with classes") would remove the overhead, improve the code's signal-to-noise ratio, and still not bring in most of the "bad C++" that the author is talking about. - The author seems to have chosen to define certain terms as they see fit. For instance, simplicity is defined in terms of brevity & terseness but the example used to prove the point is that Eiffel requires "character" and "integer" whereas C only requires "char" and "int". For an alternative point of view on what constitutes "brevity" and "simplicity", see the common C idioms for filtering or mapping any variable sized data structure. The only time it becomes less brief is if you rewrite it in C++ w/ STL or Boost. ;) - It's also telling that in Chapter 2 the Fibonacci counterpoint to Java is in Haskell, not C. That's because a full C program would look pretty similar to the Java program quoted, albeit without the sore-thumb of wrapping it all in a class . Anyhow, I should quit ranting but IMHO (a) you should know C, (b) you should respect C but (c) you should know some other languages and use C only when you actually need to. (c) may not apply if you're a super-whizz genius C programmer, some of those people seem like they can carry off ridiculous use cases without making horrible messes. Most of us are not those people. ;)