81–90 of 127 posts
I am not sure how applicable it is to an introductory text, but I would be interested in learning more about the internals of compilation and linking. What is the minimal necessary amount of work that needs to be done to interact with existing C libraries (header files, ELF format, and how that all fits together).
I'll encourage reusing existing code/libraries.
Illustrate the differences between IDB and UB early on.
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…
Earlier quoted context omitted.
I don't think the learner would appreciate the subtleties, and I don't agree that they'll learn anything from it. I can reinforce each lesson/problem you're describing one by one through the exercises, but a new person simply wouldn't know good code if it slapped them in the face. Confer with Learn Python the Hard Way to get a feel for the aesthetic and technique I'm working towards. I don't want to write bulletproof…
If you're not qualified to meet that standard then don't write a C book (or learn more before you do). C programs are either bulletproof or they are a hazard.
Reading through Zed's tutorial reminded me of some Pascal and C tutorials I downloaded in the old BBS days. They were a great introduction to both languages when I was just learning to program. I just had a look on simtel but I couldn't find them. Maybe you should put some effort into scanning old software archives and seeing if you can unearth them. C is pretty old - you wouldn't be the first one that had this idea.
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…
However, none of the Little ___er books are, of themselves, good ways to learn to use the language they are in; they're more like finger exercises when learning piano -- they reinforce your mental muscles to make thinking in the right way for those languages feel more natural.
I'm not sure it makes sense any more to teach C to beginners -- by the time someone has a need to write C code, they really ought to have mastered programming in another language or three, first. Personally, I think a teaching/review ladder would be as or more helpful than a tutorial text. Getting good at C, at least from my current starting point, seems to mostly be a matter of discipline and practice. I'm thinking…
Good thing I'm not writing it for beginners.
>I'll probably be releasing code from my first medium-sized C project in a week or so... anyone care to offer tips on how to get more experienced eyeballs on it?
Uh, that's a toughie actually. IRC can be pretty rough.
- Please make it bulletproof code, as mentioned above. I would hate to spend time relearning C the hard way AND the wrong way.
- Please get me to the point where I can make use of other libraries effectively. I'd like to understand the include/linking process at least as thoroughly as I understand python's import process.
- Please prefer readability over cleverness.
Thanks.
Earlier quoted context omitted.
If you're not qualified to meet that standard then don't write a C book (or learn more before you do). C programs are either bulletproof or they are a hazard.
On the bright side, forcing yourself to write bulletproof code for the book may well be the best way to become qualified.
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…
On the other hand, not all C code have to be secure. If I'm building a game for the Wii, don't bother me with stack overflows. The same goes for all the simulations out there (C is used about as much as Fortran in research). That's a lot of code.
Might as well put Lance Armstrong on a bicycle in front of a 5 year old and expect them to learn how to ride a bicycle by watching Lance go in a circle.