> C is easy to learn, because it's a small language.

I'm no great c or c++ programmer - but I really like Bjarne Stroustrup's "Learning Standard C++ as a New Language" (C/C++ Users Journal. pp 43-54. May 1999):

http://www.stroustrup.com/new_learning.pdf

Even if it is somewhat dated now - I think it makes a great case for c++ (or d, maybe rust) over C - and it doesn't even touch on Unicode - simply memory management, error checking and buffered I/O.

I agree everyone should know some C - and some assembler (if for nothing other than looking at compiler output) - but I'm not sure I agree that C is "simple". And learning from k&r might not be the best approach today - rather read sources of something like some of the openbsd utilities, redis, spiped...

I kinda disagree. A small language is one thing, but to "learn a language," (to be productive) you need to know the ecosystem, idioms, libraries, etc. A lot of people say design patterns are language smell--deficiencies in the language. For example, the Group of Four's book was for C++ at the time it was written. True or not, my point is that it's a part of being productive in that language and part of "learning" it. K&R and nice and short, but I've heard it argued that it doesn't teach the best (modern) C practices.

C was probably the first language I learned, but I wouldn't say I "know" it. I still have no idea which calls are safe or preferred or how to structure a larger program.

It depends what you want to get out of it. If you want to learn for its historical value, to learn more about the language that a majority of other languages adopted ideas from, K&R is probably good enough. If you want to grok a bit of random C code, that might be good enough, too, but you'll probably need a bit more. If you want to contribute to the Linux Kernel or similar project, or even put C on your resume, that's definitely not enough.

> "Nevertheless, I don't think anyone should call themselves a (true) programmer unless they know C."

You could make an even stronger claim about knowing an assembly language. The point being that understanding how a computing device works is helpful in getting the best out of it. If that wasn't your point, then C is no more special than any other popular programming language.

Also, whilst I only know the basics of C, it's pretty clear things have moved on considerably since the days of K&R. It doesn't cover any of the enhancements included in C99 and C11, nor does it cover the tooling and coding conventions (the ones that help avoid problems) that have become commonplace since 1989.

For a more up-to-date reference, I've heard good things about 21st Century C:

http://shop.oreilly.com/product/0636920033677.do

> If that wasn't your point

It wasn't; it is perfectly possible and normal to use C as one would any other programming language, i.e. without knowing much about the computer architecture. Even the pointers, often seen as something low-level, aren't really: the rules of their behavior and use are very simple, and they are easy to describe at a high level.

C is special in that, as I said, it has been, and remains, a very important programming language in its ubiquity and sheer power.

> "C is special in that, as I said, it has been, and remains, a very important programming language in its ubiquity and sheer power."

In that case, you could say the same about Java, Python, C#, etc... If being a "true" programmer is just about getting the job done, any of those languages will suffice. C may be a useful tool for certain performance critical code, but that's a very small fraction of what's required in most day-to-day programming activities. I would say the following list describes the key qualities of good code (in the order described, from most to least important, for most cases):

Correctness, clarity, conciseness, performance.

As for pointers, you can describe them at a high-level but to understand why they're a low-cost abstraction it's helpful to understand how computers work. That's the type of knowledge that C can help expose you to.

Any modern introduction to C should make heavy use of Valgrind at the very least. In addition to catching the nastiest class of bugs C programs are heir to, it can be used to teach how memory works at a low level.

can you recommend any books that introduce the concept well?

I've been using C# on a daily basis for ~2 years at this point. I've had that book on my wish list for awhile, but wasn't sure if I would make use of it - I'll likely order it soon.

K&R is a great book and should be read by everyone both for culture and as a model of technical writing.

After working through the problems, two books that would be great followups are Hanson's C Interfaces and Implementations and Bryant and O'Hallaron's Computer Systems: A Programmer's Perspective.