Learn C the Hard Way: A Clear and Direct Introduction to Modern C Programming
amazon.com
amazon.com
Such BS ad-hominen are not really need. As for the review, the first 12 paragraphs are empty blathering, and then we have empty criticisms that misunderstand the whole logic of the book. For example:
>So, finally printf() gets introduced. The author fails, in my opinion to explain what it actually does. This has the reader using format strings before even explaining (even briefly) what a format string is. This has become a repetitive theme in this book, and if I were a novice, I'd find it very confusing.
The whole idea of the book is that you learn by doing and repeatition first (like a kid does when learning to speak), and then you're told the concepts and details.
http://zedshaw.com/about/ "I am Zed A. Shaw and I write for fun and profit."
That is he is a writer, in a world where logic and reasoning applies.
The K&R book tells you all the ins and outs of the C language. The Shaw article gives you a practical way to build a program with the C language.
I would assume that an experienced programmer, such as the writer of this article seems the be, would understand this.
Most of it seems to be pedantic complaints stemming from the author’s overly literal interpretation and incomprehension of Zed’s sometimes ironic writing style.
Adds later note inline to explain that he really does know what he's talking about, and any accusations that he doesn't are either pedantic or comprehensively challenged.
Fails to reflect on how this may relate to the subject of the review.
His approach is that new developers need to get something that works so the reward of it working is motivating before you explain how/why it works to them.
Based on my experiences with my kids I think it's a perfectly valid approach - an led that turns on motivates them to understand why it turns on.
- He repeatedly states that processing an invalid C string can loop infinitely, but it can't - except in extremely rare cases on exotic systems, which seem to be the exact opposite of what he's going for. In reality it will always crash (unless being exploited by an active attacker!). The hentenaar.com post already notes this, but this instance of him being objectively wrong is buried among a huge number of more stylistic and debatable points.
The error is not a big deal, since neither looping infinitely nor crashing is desirable, but I can't help but think it demonstrates the author's lack of experience in what he's supposed to be teaching.
- Also wrong: "The source of almost all bugs in C come from forgetting to have enough space, or forgetting to put a '\0' at the end of a string." Forgetting to null terminate is a newbie mistake. A claim that almost everything that can be incorrect about a C program comes from a buffer overflow seems obviously spurious, so I'll give the benefit of the doubt and assume he's referring to security problems. In that case, some bugs involve straight buffer overflows, but a good fraction of real-life security bugs involve other things like integer overflows and use-after-free.
Also not exactly a big deal - perfectly sufficient to worry about overflows just because they account for many bugs, rather than almost all - but it seems myopic with respect to real world code.
- "In fact it's so common and hard to get right that the majority of good C code just doesn't use C style strings." I guess it's technically subjective what counts as "good", but most C codebases use C strings to some extent, so this is pretty misleading.
As one example, OpenSSH, despite being very carefully written code that uses a safe buffer API for the low level protocol manipulation, also uses C strings all over the place. As another, Linux is generally considered reasonably high quality, and it makes no effort to avoid C strings. I think you'd have a hard time making a long list of well-known C programs that do use alternative string libraries exclusively. (Note: this has no bearing on whether or not doing so is a good idea.)
- "In C, there's not really a 'boolean' type" - there has been since 1999; a lot of code doesn't use it, but since this is aimed at modern C, are you really not even going to mention it?
- Type Conversion section doesn't mention (or incorrectly describes, I can't tell which) the "integer promotions"; these are an awful feature and relying on them is awful, but a manual for how implicit conversions are done shouldn't have an incorrect algorithm!
Point is, it won't infinite loop.
I think all of the points you've mentioned are correct - Zed's said some stuff that isn't to-the-letter accurate. I guess the reason people get up in arms (wrongly, IMO) about pointing these things out is the worry that these details he got wrong will obscure the bigger picture of his work. I think it's a pretty silly thing to freak out about; Zed's taken a programming language that's frequently seen as daunting and difficult to learn and made it fairly accessible for a new/newish programmer. So what if he missed or misinterpreted a few finer points?
I guess that's why Zed Shaw comment threads end in flame wars on HN - half of the people are pissed at what they view as attempts to besmirch their teacher, and the other half are watching the first half get up in arms about what's essentially a code review and thinking "Jesus, you must be shitty programmers because of how personally you're taking this".
Just my opinion. Mileage may vary. :)