Zed Shaw, whilst his approach to certain issues may be questionable, is not "a writer rather than an engineer".

Zed is known as one of the most prolific and capable software engineers around and I have heard his C code for Mongrel 2 server https://github.com/zedshaw/mongrel2 described as being amongst some of the best examples of C code to study, learn and understand (trying to find the link that said that). I hold his work in high regard.

I don't agree with everything that Zed does and think it's a pity that his combative and dogmatic nature detracts from the core message about his work, but the author of this blog post is off track if he is trying to suggest that Zed doesn't know what he is doing and is "a writer" rather than "a software engineer". Zed is a (cantankerous) software engineer and a writer.

The attempt to discredit Zed's credentials just discredits the blog post and its author. When criticizing, criticize the work rather than the person.

And all of the posts pointing this out all disclaim that "while they don't agree with Zed about some things..."

It's just kind of sad from a rhetorical perspective.

It's clear that the guy who wrote this post doesn't agree with Zed's pedagogical style, but that doesn't make Zed's book wrong in detail or approach. It just means this guy doesn't agree with the style. And he's not upfront about it either due to a lack of introspection or forthrightness.

Zed also made many completely unjustified attacks on the K & R book, which is a well-written, easy to read book which introducse C concepts in a clear and readable way. Even if this was justified (and it's really, really not), that all belonged as a separate blog article rather than as part of an alleged "tutorial."

Finally Zed published a "rebuttal" to all of this in which he basically says that C sucks, is not worth learning, and he's learning Go. So the author quite reasonably asks, why would you want to learn C from someone who doesn't like the language or think it's worth learning?

I think we can all agree that Go (or some other high level language) probably is the better choice for most projects. But after all, there are still many places where C will continue to be used like the Linux kernel. Those people would be much better off reading K&R, as old as it is, than anything Zed has written. And his attacks on the K&R authors are just sad.

In the discussion of C strings, the author is arguing that Zed's arguments are nonsensical, maybe even objectively wrong. I write a lot of C, and the author is right in this case about C strings and undefined operations. In C you must arrange your code so that you always supply valid input to functions, there is no way around it, and it is perfectly safe once you do so.

I'd rather see discussion of the actual arguments, rather than complaints about the article's tone. :)

And that's why this is a style issue. Even if he disagrees with Zed's approach (and in particular how undefined behavior is discussed) it's just mendacious to claim that Zed isn't introducing his readers to the idea that one needs to be careful with strings and understand what kind of inputs one will receive.

This is a critically different behavior when compared to Ruby or Python where string management is done for you, and coming from the POV of someone who's familiar with those languages... Zed's approach makes sense. Especially when the alternative being suggested is "you absolutely must go read the C spec and K&RC".

They also value the war/being right/the point more highly than they value maintenance of positive human relationship.

What they don't understand is that people forget the issue and remember the grace (or not) with which you handled it.

Often they are not very good at empathizing with others and find it hard to imagine what it is like to be someone else interacting with them.

I know cause I am one, hopefully reformed.

I wonder if it's simply a case of:

1. Zed Shaw is controversial on HN

2. I know, I'll write a post that disses Zed Shaw

3. ???

4. Profit!

He didn't say Zed wasn't an engineer. He just said that he isn't a writer so the article will be written in an engineering voice.

People do the same things with presentations. "Sorry, I'm not a public speaker, so this might suck."

A lot of really smart people are cantankerous, and often they can afford to be.

My understanding of his approach to teaching is that it's based getting people to do things that bring results and then getting them to understand why after - which I think is a perfectly sensible one for beginners

When you're cooking, you follow a recipe. When you are learning to be a cook, you graduate to figuring out why you do it the way the recipe did.

And when you get really good, you start saying things like "Well, I wouldn't teach people to cook THAT way! That's wrong!"

:)

His own words, strictly read, imply that:

  - Shaw is a writer;
  - The author is not a writer;
  - The author is an engineer.

By implication, Zed's book is not written from the POV of an engineer (otherwise why would this be worth noting in any way shape or form? The topic under discussion is already software engineering).

"Wait a tic... Where's the Makefile? I've got just about as much chance of finding it as the FBI does of finding Jimmy Hoffa. Am I just supposed to imagine it into existence?"

I think the point is that the make command can use implicit rules even if there is no Makefile. It knows how to compile C source files. (This could be confusing if you know about "make" but don't know about implicit rules.) For example:

    $ ls
    hello.c
    $ cat hello.c
    #include <stdio.h>
    int main(void) {
        puts("hello");
        return 0;
    }
    $ make hello
    cc     hello.c   -o hello
    $ ./hello
    hello
    $

Yes, that's exactly what you're supposed to do. Try it, it should work.

Part 10 mentions strncpy() as a safer strcpy(). It isn't. http://the-flat-trantor-society.blogspot.com/2012/03/no-strn...

(Disclaimer: I haven't read Zed Shaw's book, and I don't intend to.)

That being said; it is a safer alternative to strcpy, but it seems like it isn't the safest alternative to strcpy.

strcpy, when used as designed, always leaves the target array properly null-terminated. Using it properly is a bit more difficult; you have to make sure the target array is big enough to hold the source string.

This sequence:

    target[0] = '\0';
    strncat(target, source, sizeof target);

Things like:

1. Griping about format strings not being explained until it's necessary to understand them even though it's suggested that you look into them right away in the extra credit section.

2. Griping about non-existent Makefiles even though they are explained in multiple sections, one where he chose to spend time dissing on the section title instead of actually reading it and seeing that you write a makefile.

It feels like the author believes that there's a "one true way" to teach a language and that Zed's way isn't it.

I for one am grateful for alternatives to textbook-style books, be it Learn X the Hard Way or the O'Reilly Head First books.

Yeah, this was the fist sign I wouldn't read to the end, and I was right. The author just says this, and leaves it at that. As if we are to just take his word for it. This is essentially what this argument boils down to:

"He said X, I say X++." No explanation, nothing to backup what he says, nothing other than a to suggest it's a epic understatement.

Let's put this another way: my comment is has more to backup what I say than this article. The author might be right, but he doesn't back it up.

  >more hello.c
  int main(int argc, char *argv[])
  {
    puts("Hello world.");
    return 0;
  }

  >cl hello.c
  Microsoft (R) C/C++ Optimizing Compiler Version 
  18.00.31101 for x86
  Copyright (C) Microsoft Corporation.  All rights reserved.

  hello.c

  Microsoft (R) Incremental Linker Version 12.00.31101.0
  Copyright (C) Microsoft Corporation.  All rights reserved.

  /out:hello.exe
  hello.obj

  >hello
  Hello world.

My reading was that the author just didn't know about implicit make rules. Shaw's book apparently suggests using "make" to compile and link a simple C program. The author goes on at some length about not being able to find the Makefile, apparently unaware that no Makefile is necessary.

The "make" command is rarely used without a Makefile, so this is a fairly easy mistake to make.

Now try it using some features from that super-recent, edgy, C standard from 16 years ago, C99.

In what sense? MS platform had a working C compiler for decades.

Were there any (free) IDEs that took advantage of this? I thought one of the reasons Stevens used DJGPP was that MSVC wasn't available for free? I suppose I could just be that it wasn't freely distributable, which makes it hard to bundle with a book (at a time when people can't just go and download megabytes of data from microsoft.com).

Or maybe MSVC was free, but not the c++ part? See eg:

http://www.atarimagazines.com/compute/issue162/52_Windows_pr...

(It's not my intention to move the goalposts, you say close to a decade, which means 2005 -- it's quite likely that I'm just biased due to my old age...)

I did find this: http://blogs.msdn.com/b/vcblog/archive/2006/06/08/622485.asp...

Which reminded me of VS express -- which isn't the same as a full version (but should/did work for "hello, world!"). See also eg: http://www.i-programmer.info/news/89-net/7976-full-visual-st...

How did you get a free c-compiler from MS in the mid 90s?

In the 90s though, I used the non-free VS for the most part along with some Cygwin until Mingw's appearence in the late 90s.

To get good at anything, you have to constantly read and apply your knowledge. Why should this be any different?

http://zedshaw.com/2015/06/01/dear-paul/

http://s3.amazonaws.com/hanselminutes/hanselminutes_0407.pdf

All I see is the author fussing about coding style and some such.

Because I'd like to read the K&R C destructuring book, not just a removed chapter at the end of the book :-)

I somehow thought that notion, that K&R C is somewhat outdated in their code examples is widely accepted (biggest gripe is little to no input sanitation, afaik (?)), so a book about "this is what we learned about c in past 30 years" would be splendid :-)

Hope this helps....