4 ms·

Learn C the Hard Way: A Clear and Direct Introduction to Modern C Programming

37 points by hikz 11y ago

kasabali 11y ago
http://hentenaar.com/dont-learn-c-the-wrong-way http://hentenaar.com/dont-learn-c-the-wrong-way
- pan69 11y ago
  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.
- cushychicken 11y ago
  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.
- jacobolus 11y ago
  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.
- yarrel 11y ago
  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.
- youngtaff 11y ago
  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.
coldtea 11y ago
>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.
- mateuszb 11y ago
  It's not ad-hominem BS. http://zedshaw.com/about/ 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.
  - wyclif 11y ago
    I don't think he meant that the "I am not a writer" part was BS (obviously Zed is a writer; the OP is a link to his book), but rather that this is posturing instead of an argument.
  - explosion 11y ago
    Is there any reason why one can't be both a writer and engineer simultaneously?
- andrewstuart 11y ago
  Also, Zed Shaw isn't just "a writer", he's known for writing some really fine applications.
- JadeNB 11y ago
  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.
saboot 11y ago
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.
comex 11y ago
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!

37 points by hikz 11y ago

kasabali 11y ago

http://hentenaar.com/dont-learn-c-the-wrong-way http://hentenaar.com/dont-learn-c-the-wrong-way

pan69 11y ago
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.
cushychicken 11y ago
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.
jacobolus 11y ago
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.
yarrel 11y ago
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.
youngtaff 11y ago
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.

coldtea 11y ago

>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.

mateuszb 11y ago
It's not ad-hominem BS. http://zedshaw.com/about/ 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.
- wyclif 11y ago
  I don't think he meant that the "I am not a writer" part was BS (obviously Zed is a writer; the OP is a link to his book), but rather that this is posturing instead of an argument.
- explosion 11y ago
  Is there any reason why one can't be both a writer and engineer simultaneously?
andrewstuart 11y ago
Also, Zed Shaw isn't just "a writer", he's known for writing some really fine applications.
JadeNB 11y ago
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.

saboot 11y ago

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.

comex 11y ago

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!