Live data from Hacker News

What do you want to see in Learn C The Hard Way?

news.ycombinator.com

121–127 of 127 posts

Re: What do you want to see in Learn C The Hard Way?

#121
post #83
post #21

whatever you do, make your examples bulletproof. even if it's not how you would normally write the code and it seems overly cautious, do your audience a favor and write the example that way anyway. if there are any buffer overflows, integer overflows, off-by-one's, signedness issues, failure to check return values of everything, use of typically insecure things like sprintf instead of snprintf, all of these problems…

One of the things that I admire most about W. Richard Stevens's books is that he checked the return value of everything, even printfs. Anal, sure, but that's what you're supposed to do in C and when you write demo code that doesn't, even if you surround it with warnings like "DO NOT DO THIS", beginners will still do it. Better to get the habits in right from the start.

[deleted]

Re: What do you want to see in Learn C The Hard Way?

#122
post #61

I understood K&R years ago, but somehow I feel completely inadequate to being a C programmer. I think there is some kind of black art involved in memory management. I checked recently and it seems K&R doesn't even talk much about memory management. I just wish to learn the current state of the art - what are best practices that have evolved since K&R?

There's a chapter on memory management* in Hanson's _C Interfaces and Implementations_ (http://sites.google.com/site/cinterfacesimplementations/), which is one of the better advanced C books I've read.

* Mostly, arena-based allocators.

Paul Wilson's "Uniprocessor Garbage Collection Techniques" (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.2...) is an excellent overview, as is Jones and Lins's _Garbage Collection: Algorithms for Automatic Dynamic Memory Management_.

Re: What do you want to see in Learn C The Hard Way?

#123
post #61

I understood K&R years ago, but somehow I feel completely inadequate to being a C programmer. I think there is some kind of black art involved in memory management. I checked recently and it seems K&R doesn't even talk much about memory management. I just wish to learn the current state of the art - what are best practices that have evolved since K&R?

There's a chapter on memory management* in Hanson's _C Interfaces and Implementations_ ( http://sites.google.com/site/cinterfacesimplementations/ ), which is one of the better advanced C books I've read. * Mostly, arena-based allocators. Paul Wilson's "Uniprocessor Garbage Collection Techniques" ( http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.2... ) is an excellent overview, as is Jones and Lins's _Garba…

Interested parties can also look into "Memory as a Programming Concept in C and C++".

Re: What do you want to see in Learn C The Hard Way?

#124
post #86

I think it would be cool to see any of the following: Learn Haskell the Hard Way Learn Erlang the Hard Way Learn Common Lisp the Hard Way Learn R the Hard Way Besides a "Learn X the Hard Way", I would actually like to see more people try to recreate the style of "The Little Scheme", which uses the socratic method to teach the learner. I think the socratic method requires the user to rack their brain a bit more, but r…

There _is_ a Little MLer (with examples in Caml and Standard ML), which teaches type-based programming very well, and would be worth reading for anyone setting out to learn Haskell, I imagine (I respect Haskell's purity, but program in ML and Scala, the same way I respect Ada's safety, but program in C, so a better Haskeller than myself may disagree. :-)). However, none of the Little ___er books are, of themselves, g…

I agree that "The Little ____er" books aren't the best to learn how to apply a language in the real world. I also agree with your "piano finger lesson" analogy.

However, where "The Little _____er" books excel and overcome all other teaching formats I've seen is in introducing complex paradigm-shifting concepts in a way that is digestable in tiny chunks.

Concepts such as monads, zippers and list comprehension are exactly the the type of concepts that are very difficult to teach/explain using common teaching approaches that "tell, but do not show"

The socratic method used in "The Little Schemer" makes sure to dismantle these extremely abstract concepts into atoms '(pun intended). You really need to understand each atomic piece before you move on.

In most explanations of monads the teacher rattles off a long run-on sentence that touches on several facets of a concept such as monads, making it all that much harder to digest. In fact, most sentences/paragraphs attempting to explaining monads just cause the learner to choke on the terseness and density of information being communicated in one utterance.

The way I see it, both types of books are very valuable. The Little Schemer teaches recursion as a concept better than any other text I've seen. I've never seen anything else that come close. In fact, most texts that touch on recursion quickly move into comparing it to iteration both in form and performance. SICP is an example of a teaching resource that does this. If I remember correctly, the first time you really see recursion in SICP is when the book discusses Ackermann's function and the pros and cons of recursion versus iteration.

Re: What do you want to see in Learn C The Hard Way?

#125

Earlier quoted context omitted.

Even better, make sure you explain function pointers well.

Even better, I'll explain when and why to use function pointers (finite state automata are a common use case)

I think a more common and more important use is callback functions.

Re: What do you want to see in Learn C The Hard Way?

#127

Earlier quoted context omitted.

Some years ago, I ran across and saved off a copy of a some-dozen page reference, in PDF format, titled something along the lines of 'everything you (will) ever need to know about pointers (in C)'. It appeared to be quite well regarded. But, that laptop was ripped off and the particular file appears not to have made it into backups. Does this description happen to ring a bell? Any references?

Might it be this?: http://boredzo.org/pointers/ or possibly this (pdf warning): http://home.earthlink.net/~momotuk/pointers.pdf

The second link, I think.

Note that it's also available in an HTML version, at:

http://pweb.netcom.com/~tjensen/ptr/pointers.htm

Post reply on HN