It's tempting for us, as programmers, to consider Python an easier language to learn than C. I'm not so sure. Python is simple for programmers to learn because it uses a large number of common programmery things: lists, hash tables, classes, modules, etc. Things that beginners won't have a clue about. C doesn't have any of these.

Sure, it takes a while for you to wrap your head around pointers. But it also takes a while for you to wrap your head around inheritance. By virtue of being a smaller language, C has less of these things to wrap your head around.

If you need a dynamic array, you have to build it yourself from what you already know. Instead of having to learn yet another opaque concept, you're reinforcing your knowledge of pointers and dynamic memory allocation. Double benefit!

And once you know C, it can give you a boost towards learning other languages - most of them are implemented using C! If I don't understand something, I can always look at the source to see how it works. Since they're implemented in C, many languages tend to map easily to C concepts.

The same cannot be said about going the other way. A Ruby programmer learning C has to unlearn all the assumptions and niceties Ruby has spoiled them with. How much of Ruby is going to be applicable to C?

Python might not be an easier language to learn than C, but it certainly an easier language to be productive in. Unless your student is highly motivated you will need more exciting examples than writing your own dynamic array to keep him going. Building things that actually do something useful is nearly impossible for a beginner using C, but definitely within reach if you leverage Python's huge libraries.

As long as you want to teach someone programming and not computer science I think a high level language is much better suited.

I just think when you're learning how to use lists and hash tables, you're learning how to abstract, decompose, solve problems, which is the 'science' part... when you're learning about pointers, also, but the emphasis is more learning about the 'computer' part .

If you want to do 'computer science' or engineering, eventually you have to learn both.

But for a beginner, who might end up just casually coding as part of another discipline, or wants to understand computers as part of a liberal arts education and never goes past the first language, I think the higher level abstractions are a better place to start. (And the languages are a little gentler)

> A Ruby programmer learning C has to unlearn all the assumptions and niceties Ruby has spoiled them with.

Only if he wants to learn C.

But why bother? For the overwhelming absolute majority of programmers it's a complete waste of time.

There's so much existing C code in the world powering almost everything we do that you just have to know C in order to get a thorough understanding of computing.

C is to computer science as latin is to medicine. All medical doctors need to know a little bit of latin

A month ago I went to advice the teacher of a high-school level video game design program about the curriculum of the program. I'm a C/C++ developer, but I too thought as you did that introducing a bunch of high school kids to programming using C or C++ would be too hard.

The school in question is mostly low-income kids looking for a vocational experience, so we expected a bunch of kids who would be out of their depth if thrown in without a garbage collector. But then the teacher mentioned that none of the kids had a hard time learning C or C++, pointers included.

So the group of game developers who had come to advice pretty much all agreed that learning C/C++ first was actually the best thing that could happen to those kids. Show them C first to teach them what the machine is REALLY doing (with only a minimal abstraction layer), give them OOP with C++, and THEN transition them to a scripting language and higher level environment so they can produce something interesting before the class is over.

I agree. C is a great language to learn at first. It's exacting and forces you to think like a programmer, but it isn't that hard to do very basic things. It's only when it comes to building larger, useful programs that it becomes difficult. The key though is you learn a lot of low-level stuff that's really useful later.

Our goal was to efficiently prepare a bright non-programmer to an entry level .NET support job. Python and Ruby are great (I hack in both daily) but each is a diversion from the stated goal. By contrast, K&R is only 228 pages and is a good introduction to C#.

K&R isn't a good introduction to modern C programming. Even the ANSI edition of the book is outdated. There are better intros in the forms of books and web sites.

Yes but K&R is a classic. Its clear style paved the way for programming books ever since. You are correct that the standards have evolved over time but remember the employer in the discussion doesn't need a C programmer, they need a .NET developer. This dude will probably never write a single line of C. Spolsky recommends K&R because it's a good test and it teaches a methodology that serves a student well in .NET. And it's only 228 pages.

> C is a masterpiece of elegance and simplicity and gives you a mental model of how a real computer works

It used to. Now, with multicore systems and out-of-order execution and cache and nearly everything else that makes modern hardware fast enough to use, it is an over-simplified view of the abstraction the hardware wants you to see, but is not detailed enough to guide you when you need extra performance.

As an example, C says nothing about cache lines; its memory model is completely flat. Cache is ideally 'transparent', but we all know that cache hits are a lot faster than misses. C gives you no guidance on how to arrange your data structures to ensure as many hits as possible.

So why draw the line there? Why is it ok to abstract away modern hardware, but not ok to abstract away memory management or pointers?

You can write a useful program that only uses one core. You can't write a useful program that doesn't use memory.

But you can write a great deal of useful code that never does any manual memory management.

You asked where you draw the line. My point is that there's a real difference between not using a resource (more than one core) or using it without understanding how it works, because it's hidden behind a paper curtain.

Because understanding pointers makes understanding references a lot easier.