Learn C The Hard Way

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, people teach libc string APIs like scanf() and strtok(), which should almost never be used. (See http://vsftpd.beasts.org/IMPLEMENTATION for one take.) Instead, use http://git.gnome.org/browse/glib/tree/glib/gstring.h or write your own like http://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-string....

If you're going to display user-visible text, you are pretty much required to link to GLib or another Unicode library, since libc doesn't have what you need (unless you want to use the old pre-unicode multi-encoding insanity).

Don't use fgets() and other pain like that, use g_file_get_contents() perhaps, or another library. (g_file_get_contents is in http://developer.gnome.org/glib/stable/glib-File-Utilities.h...)

You need help from a library other than libc to deal with portability, internationalization, security, and general sanity.

Maybe more importantly, a library will show you examples that in C you can still use all the good design principles you'd use in a higher-level language.

I told someone to "use a string class" in C recently for example, and they said "C doesn't have classes" - this is confusing syntax with concepts.

C requires more typing and more worrying about memory management, that's all. It doesn't mean that all the best practices you know can be tossed.

There's a whole lot to be said about how to write large, maintainable codebases in C, and it can even be done. It's not something I would or do choose to do these days, but it can be done.

One other thought, two of the highest-profile C codebases, the Linux kernel and the C library, have extremely weird requirements that simply do not apply to most regular programs. However, a lot of people working in C or writing about C have experience with those codebases, and it shows.

Yes, I do. But it's not because of the language itself. It's trying to figure out what you can do with it after you grasp the fundamentals. I taught myself C using K&R a long time ago, but I never did anything with it. At the time I figured there were two paths I could progress along - UI related (e.g., a Windows app) or systems related (something Unixy). Both paths presented large hurdles. Nothing insurmountable, but I wasn't a programmer at the time - just doing it for my own edification. I always thought it would be nice if there was a second level book that took you from post-basics to writing something useful.

- The concept of a variable, and variables changing over time, seems quite difficult for people to grasp even when explained a few different ways. "x = 5" followed by "x = 12" proves quite mystifying, and "x = x + 1" even more so. People seem to have the most success with the idea that declaring a variable "int x" creates a location x which can hold an int, and you can put things in that location.

- Pointers actually don't seem to trip that many people up initially, once they get to that point. However, I don't think people actually understand exactly what they do, so much as memorize the rules for dealing with them. The same idea of a location to put something applies here too.

- Any case where the same function gets called more than once often ends up tripping people up; this applies particularly to recursion, but it can happen even when just calling the same function several times. In particular, this often interacts badly with people's understandings of variables. People need some understanding of scope.

- Combining several of the above, it would help to have clear explanations of the interactions between pointers, locations, and functions. Bonus for explaining what goes horribly wrong if a pointer refers to something that goes out of scope. That concept requires understanding several different pieces of C and putting them together.