Live data from Hacker News

Learn C The Hard Way

learncodethehardway.org

201–210 of 260 posts

Re: Learn C The Hard Way

#201
post #168

Earlier quoted context omitted.

You should stop thinking everyone is attacking you. I think you'd be happier. Really though, there's no content here. The fact it's been voted to #1 on hackernews shows just how bad things are. Items should be upvoted on their merit, rather than who did them. Someone writing another book about programming C isn't newsworthy.

Someone writing another book about programming C isn't newsworthy However, "someone who wrote a ground-breaking introductory book in xyz modern-popular-hip language is turning his attention to C, of all things" is newsworthy.

I had to stop reading at "ground breaking". I'll assume you're being sarcastic and leave it at that :)

Re: Learn C The Hard Way

#202
post #10
post #3

I look forward to the content. As a beginning C++ instructor I find there is something lacking between the truth of the language and the conventions for presenting it. Nobody, AFAIK save for the truly hardcore student, has nailed it.

Got any feedback on the things students get wrong? My experience is they fail to grasp memory management, pointers, functions as pointers, linkers or just how a program actually runs. If you've got others I'd love to hear them.

Too often we think of C in terms of commands. C is a matter of _operators_. Consider "=", say in the statement

y=1+x=3;

Why and how this works is foreign to most beginners. Likewise (ok, this is C++ but the point remains)

coutIsn't a command to display 1+x. The output is the result of inserting the computed value into couture. There is a semantic difference.

Groking operators early is key to understanding C well.

Re: Learn C The Hard Way

#203
post #82

Ohloh says I've changed at least half million lines of C code ( https://www.ohloh.net/accounts/rhp/positions/total ) Play me a tiny violin ;-) What kinda bugs me is that whenever people go to teach C, they make out like it _has_ to be a low-level exercise, as if writing in C suddenly means you can't use abstract data types or object-oriented style or name your functions properly or have Unicode support. For example,…

I'm glad you got so much about how my book is written from a few paragraphs in an unfinished manuscript for it.

Hey, Zed, can you tell us all how much we're losers because we don't get as many blog post hits as you? The irony was a big hit last time.

Re: Learn C The Hard Way

#204

Earlier quoted context omitted.

You should stop thinking everyone is attacking you. I think you'd be happier. Really though, there's no content here. The fact it's been voted to #1 on hackernews shows just how bad things are. Items should be upvoted on their merit, rather than who did them. Someone writing another book about programming C isn't newsworthy.

I don't really understand your comment. 1. The post is about Zed's draft; is it really so far of a leap to interpret hp's remarks as a criticism of the book? 2. Is this a fair paraphrase? "Everyone here isn't attacking you, also, your draft sucks and shouldn't have been posted on HN."

1. I agree 2. He didn't post it someone else did, and no, I don't think it should have been posted.

Re: Learn C The Hard Way

#205
post #171

Earlier quoted context omitted.

"This isn't the only possible interpretation of that comment" Genuine curiosity... what other interpretation could there be? Is it an ESL issue with literal translation causing offense? Or is there another interpretation in a non North American culture? In N.A. at least, this is an extremely common expression.

By "that comment", I meant hp's original comment, which was a long tangent on how to go about teaching C, in the context of a post about a draft of a book teaching C. The piece that X-Istence isolated contributes to the interpretation that the comment was a criticism of Shaw, and not just a long tangent. It can be read as setting a confrontational tone. I don't understand why other commenters feel it was unreasonable…

  I don't understand why other commenters feel it was 
  unreasonable of Shaw to interpret it as a criticism.
To speak for myself: because the other interpretation makes much more sense, if you take into account that people are generally trying to be nice and helpful.

I was reading that comment, thought "hmmm, that criticism sounds a bit premature and more based on what others have written than on what Zed is writing... oh wait, that's because he isn't saying anything about Zed's writing at all. Yeah, now it makes perfect sense."

So admittedly, you get confused for a moment, but then there's a perfectly obvious solution: he's not commenting on the linked article, but is offering advice in the form of criticism on what generally goes wrong with these projects. If you don't see that solution and don't go for that interpretation, I think it means you fail to consider the option that someone is just being clumsy at being helpful. So it's another instance of Hanlon's razor: don't attribute to malice what could equally well be explained by stupidity (which is of course much too strong a term for an awkwardly phrased anwer).

BTW, it's not right that your comments are being downvoted.

Re: Learn C The Hard Way

#206
post #56

Earlier quoted context omitted.

C is difficult, yes. Dangerous - I don't know in what sense. I manage to get more exceptions in my Python, Ruby code, owing to undefined variables or incorrect types, than I get segfaults in C. The main issue with C is it takes some time before you are ready to take it head on. An experienced C programmers would have his repertoire of generic data structures library with time complexity guarantees (programs without h…

"I manage to get more exceptions in my Python, Ruby code, owing to undefined variables or incorrect types, than I get segfaults in C." What happens when you don't get a clean segfault is what got C the "dangerous" reputation.

If you are developing, `gcc -g` while compiling(or CFLAGS += g), and loading the core with gdb does give a very good idea of what went wrong.

Re: Learn C The Hard Way

#207
post #56

Earlier quoted context omitted.

C is difficult, yes. Dangerous - I don't know in what sense. I manage to get more exceptions in my Python, Ruby code, owing to undefined variables or incorrect types, than I get segfaults in C. The main issue with C is it takes some time before you are ready to take it head on. An experienced C programmers would have his repertoire of generic data structures library with time complexity guarantees (programs without h…

what I keep repeating about that is why the C standard guys don't freaking update the libc with a new version of the C standard? Deprecating the old silly stuff like strcat() (the libc is full of bad calls) and adding lists, hashes, btrees, good dynamic strings lib, and so forth. An huge step forward for C... without even touching the core language.

A bit OT and not sure if you will see this.

Seeing that you are the guy(or onof the guys) behind redis which is written in C, do you have any recommendations for generic data structures and operations on them?

I personally have a trivial vector implementation which resizes when full, and a red-black tree implementation for associative arrays. Both of them work fine for my purpose - does the job, good locality of reference, generic over void*.

I have seen glib but largely neglected it because I only need a very small part of it.

Re: Learn C The Hard Way

#208
post #186
post #170

Earlier quoted context omitted.

can you get around the second without typeof(a gnu extension)?

at least if you stick to macros

You can't, unfortunately. The point is to be cognizant of the fact that expressions will be evaluated for their effects more than once (maybe). So, don't put effectful things inside a macro expansion.

Re: Learn C The Hard Way

#209
post #206

Earlier quoted context omitted.

"I manage to get more exceptions in my Python, Ruby code, owing to undefined variables or incorrect types, than I get segfaults in C." What happens when you don't get a clean segfault is what got C the "dangerous" reputation.

If you are developing, `gcc -g` while compiling(or CFLAGS += g), and loading the core with gdb does give a very good idea of what went wrong.

It is a lucky scenario when you actually get a core and one taken at the exactly right time. Unfortunately there are some pointer bugs that are hard to find even with Valgrind.

Buffer overflows do not produce cores, they just sit there until a determined cracker makes use of them. And a dangling pointer might still access memory that looks valid both to OS and memcheck.

Re: Learn C The Hard Way

#210

Earlier quoted context omitted.

By "that comment", I meant hp's original comment, which was a long tangent on how to go about teaching C, in the context of a post about a draft of a book teaching C. The piece that X-Istence isolated contributes to the interpretation that the comment was a criticism of Shaw, and not just a long tangent. It can be read as setting a confrontational tone. I don't understand why other commenters feel it was unreasonable…

I don't understand why other commenters feel it was unreasonable of Shaw to interpret it as a criticism. To speak for myself: because the other interpretation makes much more sense, if you take into account that people are generally trying to be nice and helpful. I was reading that comment, thought "hmmm, that criticism sounds a bit premature and more based on what others have written than on what Zed is writing... o…

Yes, I agree that Shaw didn't apply Hanlon's razor here, and ought to have.
Post reply on HN