Hacker News Reader

Your dismissal of his Python material is unfounded. This book is quite good, especially for beginners that literally would be unable to learn to code otherwise.

As a professional educator myself, I strongly disagree with your sentiment about "teaching dangerous practices to beginners". By far, the biggest "danger" to beginners is that they won't learn how to code at all or get frustrated and quit because of pedants.

Do we teach beginning drivers using 18-wheeled tractor trailers? Or using F-15 fighter jets? No, we use cars with automatic shifting driving around in an empty parking lot at first.

I don't think your analogy really makes sense; the issue isn't that the author tries to teach people things which are too difficult to handle but that the author may state things which are just incorrect. A better analogy would be teaching beginning drivers to use their knees instead of hands to drive.

I suppose I'm in a different position than you though; I don't see any need to get everyone to start coding. I think if people want to code there are already good books out there, and if they don't then I don't think we need more developers who hate their job.

What about the C book is incorrect? I want data and citations.

I'm not sure if you're being sarcastic but I'll respond in case you aren't. I don't recall saying that I thought there were mistakes in the book; I wouldn't know I haven't read it.

The person I was replying to just didn't seem to understand what anon1385 was trying to say; it's difficult to recommend a book written by someone who writes and teaches on topics he/she doesn't fully understand. There was a link to a thread where the author of a book on C was wrong about one of the fundamental aspects of the language.

Again, I don't have the slightest idea whether there is wrong information in any of the author's books, but I can also see why one would be wary trusting a book written by someone who has shown a serious lack of mastery on previous occasion.

I believe the person I was replying to misunderstood the cause of concern as being one where a person is taught poor or suboptimal practices as opposed to one where a person is taught things which are just flat out incorrect.

So IOW, you don't actually have a valid criticism of LCTHW. Got it.

Indeed. No idea why you thought I was attempting to criticize it, validly or not. I was just trying to elaborate on a previous comment that someone else seemed to have misinterpreted.

When I started to learn python, I bought his book. It was okay.

I actually found youtube tutorials,videos,and codeacademy to be far more interesting and effective.

I don't think I would recommend a book to a pure beginner anymore, places like code academy have matured to be far better.

It's interesting that you'd use an anonymous account to sling some slander, but I'll answer you:

Yep, that comment thread is great and people should read it for an explanation as to how completely insecure C is. It made me realize that nobody can teach C safely. Not me, not K&R, nobody. The language is completely unsafe by design. If you think K&R could, you should realize that they fixed the code in the book numerous times to make it more secure during it's 40+ printings.

Based on that, I killed my darlings. I should have never started this book as a "C book". I rewrote about 50% of it to instead focus on the things a mere mortal like me can teach:

  0. How to learn any programming language quickly with some tricks I know.
  1. Secure programming and defensive coding skills, which a broken language like C is perfect for teaching.
  2. Testing and reliability.
  3. Most of the C I've found safe and useful, and how to avoid UB when possible.
  4. Algorithms and how to apply them.
  5. And finally building projects as small challenges to get better at C.

So everyone was right, and I adapted the book to denote that. I also started a project, which hopefully I'll find time to do, that is going to catalog all of the UB in C, write a unit test for each one, and then attempt to assess the security failures of it:

https://github.com/zedshaw/cubfail

I'm currently finishing up a book, but this project interests me because what I've seen is most "professional" C programmers end up pulling out UB whenever they are called out on a secure coding practice they fail at. I think a good catalog of how to cause security failure with C UB would be instructive to everyone.

And then we can all just stop using C. It's terrible.

Now that you have this new information, hopefully you'll update your slander.

I'm just commenting from the position of an observer who has found that your general attitude undermines the work you do, irrespective of whether you are right or wrong about the issue at hand.

We are all wrong at times. There is no shame in that. But finally admitting fault after months of intransigence (I'm taking about from the launch of the book, when people first started criticising it, until that thread) doesn't excuse your behaviour prior to that. With a bit more humility from the beginning none of this would have happened. If you are going to pick a fight with people, C language lawyers are probably about the worst target.

I don't care about "winning" the argument - just about everybody already agreed that C is highly unsafe, and personally I think K&R is quite outdated now, since it doesn't dwell as much as it should on all the dangerous and difficult aspects of C. Much like C itself, it generally assumes superhuman competence on the part of the reader.

Putting that aside, I do think we are lacking in resources that teach people about the many pitfalls of C in one place (if only to scare people away from the idea of using C for anything network facing). Especially in an era when a lot of people learning C are probably already familiar with the basic syntax and control flow, through knowledge of Java or other languages, and will thus probably be tempted to skim through beginner C books. People coming from that direction probably find C deceptively familiar, and aren't aware of a bunch of things like the undefined behaviour of certain integer overflows and shifts, or the strict aliasing rules, or possibly even reading uninitialized variables.

John Regehr has a lot of good blog posts on this topic:

http://blog.regehr.org/archives/1054

http://blog.regehr.org/archives/1136

http://blog.regehr.org/archives/959

As you can see in some of those examples UB can be very difficult to spot, even for experts like compiler engineers or crypto developers who are intimately familiar with the rules. Also some things are just plain tricky to do correctly and efficiently (e.g. http://blog.regehr.org/archives/1063) and in the past compilers were much less aggressive about optimisations that affected code containing undefined behaviour. So you could get away with it, and incorrect code became the accepted way to do some things. This resulted in a lot of gnashing of teeth and a few well known security vulns when old code started to break with newer compilers.

If you are looking to catch bugs and undefined behaviour in test cases you should certainly look into the -fsanitize options in clang. This post gives an introduction: http://blog.regehr.org/archives/905 and the up to date docs are here: http://clang.llvm.org/docs/UsersManual.html#controlling-code...

> The take aways are that Zed doesn't understand C and hasn't read the C standard.

This statement is quite unfair. I have read the code from Mongrel2 and I've learned things which completely eluded me in the past. Have you considered that he is actually a human being which can be surprised at how an old book can present aspects never noted before?

Just because he hadn't thought about that particular language horror side effect doesn't mean he doesn't understand C. C can be manipulated in horrific ways, such as a psychopath can absolutely horrify you. That doesn't mean you don't understand life for example.

And no, he doesn't mock people who read the standard. The discussion was entirely about something else. He proposed an improvement on how to handle strings and how the original K&R code should only be looked at from a didactic POV and not production level quality.

That is what I saw in that thread.

>And no, he doesn't mock people who read the standard. The discussion was entirely about something else.

Allow me to quote for you, since this comment[1] was downvoted to the bottom of that thread and maybe you missed it:

Ahhh the "undefined behavior" trope, whereby a C "expert" who's memorized a standard trots out the abstract machine to justify his point. An abstract machine that doesn't actually exist and that no computer actually functions as.

>Just because he hadn't thought about that particular language horror side effect doesn't mean he doesn't understand C.

No, really. Somebody who isn't aware of undefined behaviour can't claim to understand C. The fact that he has now changed his position on the entire language (now advising people not to use it, advice I broadly agree with BTW), indicates that he wasn't aware of these things prior to that discussion.

[1] https://news.ycombinator.com/item?id=8834947

Never heard about Zed so consider this rather objective - I just read the post and I don't think I agree with your take on it:

Just because he hadn't thought about that particular language horror side effect doesn't mean he doesn't understand C

But UB is such a key aspect, if you don't understand in full what it is, I'd say you do lack some understanding of C?

And no, he doesn't mock people who read the standard.

It is open to interpretation, but you should admit his Ahhh the "undefined behavior" trope, whereby a C "expert" who's memorized a standard trots out the abstract machine to justify his point. is rather snarky

Anybody who knows C should read this thread

People who know C are not the primary audience for Learn C the Hard Way. Every programming tutorial aimed at beginning students puts the student on a tricycle, points them toward a cliff, and tells them to peddle as hard as they can.

Norvig points out the cliff is always there.[1] Zed Shaw starts 50 lessons away from the edge. How to Design Programs puts the student at a different distance. Instruction for advanced students [working programmers] expects the student to know they are headed for a cliff.[2]

  The last compound type that we shall consider in this 
  section is the record type. Records are quite similar to 
  Pascal records and to C structures (and to
  similar features in other programming languages). A  
  record consists of a finite set of labelled fields, each 
  with a value of any type (as with tuples, different
  fields may have different types). Record values are 
  written by giving a set of equations of the form l = e, 
  where l is a label and e is an expression, enclosed
  in curly braces. The equation l = e sets the value of 
  the field labelled l to the value of e. The type of such 
  a value is a set of pairs of the form l : t where
  l is a label and t is a type, also enclosed in curly 
  braces. The order of the equations and typings is 
  completely immaterial | components of a record are
  identified by their label, rather than their position.  
  Equality is component-wise: two records are equal if 
  their corresponding fields (determined by label)
  are equal.  -- Introduction to Standard ML

[1]: http://norvig.com/21-days.html

[2]: http://www-plan.cs.colorado.edu/diwan/class-papers/ML-doc.pd...