>Let me start by saying that unlike Mr. Shaw, I am not a writer. I'm an engineer.
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.
I'm sorry for a stupid question, but from where are you quoting? As of 19:53 on 2015 April 22, the link seems to be to an Amazon page for Shaw's book, with no customer reviews.
I think the article of this author is pedantic. The articles written by Shaw will show how to create programs with a specific language such as C, Ruby or Python and the C version is, of course, no substitute for the K&R book.
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.
This critique is completely incoherent. I read the first half, and I still have no idea what the author’s point is.
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.
The reviewer fails to understand Zed's approach to teaching…
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.
Author writes review criticising book for misleading readers.
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.
This guy encloses about 3 valid criticisms (the one about makefiles foremost among them) in a huge, dogmatic screed of nitpicks that he just assumes people will read and think "he's wrong he's wrong he's WRONG" about Zed.
Is there a table of contents anywhere? I remember wishing he finished the "Let's Make a Virtual Machine" section at the end of the html preview of this book. It was never updated which was disappointing as it sounded really interesting.
Of course this comment thread is (judging by the comments so far) going to be mostly about whether Zed Shaw criticizing old fashioned C is right or not or whether the criticizers are right or whatever. Oi... against my better judgement, I'm going to call out a few relatively objectively objectionable points in the book (which are still there, as opposed to the removed K&R chapter):
- 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!
This is way more coherent than Hentenaar's screed; thanks for posting it, I've always had a hard time understanding the points articulated against LCTHW.
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".
Small correction to self: when I said "always crash" I meant if it doesn't stop itself by finding a zero byte that happen to be in memory; the exception is a rather obscure exploit scenario where an attacker takes control before you get to that point. But the most common case is of course that it finds a zero which happens to be within a few bytes of the end of the buffer, because zeroes are common.
[+] [-] coldtea|11 years ago|reply
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.
[+] [-] andrewstuart|11 years ago|reply
[+] [-] mateuszb|11 years ago|reply
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.
[+] [-] JadeNB|11 years ago|reply
[+] [-] kasabali|11 years ago|reply
[+] [-] pan69|11 years ago|reply
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.
[+] [-] jacobolus|11 years ago|reply
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.
[+] [-] youngtaff|11 years ago|reply
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.
[+] [-] yarrel|11 years ago|reply
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.
[+] [-] cushychicken|11 years ago|reply
[+] [-] saboot|11 years ago|reply
[+] [-] comex|11 years ago|reply
- 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!
[+] [-] cushychicken|11 years ago|reply
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. :)
[+] [-] comex|11 years ago|reply
Point is, it won't infinite loop.