

Learn C the Hard Way: A Clear and Direct Introduction to Modern C Programming - hikz
http://www.amazon.com/Learn-Hard-Way-Introduction-Programming/dp/0321884922/

======
coldtea
> _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
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
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.

------
kasabali
[http://hentenaar.com/dont-learn-c-the-wrong-way](http://hentenaar.com/dont-
learn-c-the-wrong-way)

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

------
saboot
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
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!

~~~
cushychicken
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".

Just my opinion. Mileage may vary. :)

