> C accurately models how the computer actually works
i don't even know on what kind of hardware my java or python programs run. neither google (appengine) nor our IT apartment tell me.
so for most app developers "a computer" is not really something they work with. of course someone must write those abstractions (python, etc), and they do it in C/C++ :)
But I can safely say that it is a machine that the C language models fairly precisely and that python, lisp etc will use in ways that will make it harder to predict how their constructs will interact with the machine.
That's exactly the point, if your machine is anywhere near 'standard' (as in not a SIMD or something exotic) then C is as close as you can get to it without going to assembler.
The only reason you know what the C you write will end up doing on the machine is because you are generally not doing much when you're working in C.
If you want to get productive work done, you'll be leveraging lots of libraries written by third parties, and you have no more insight into how they are working when you're invoking them with C than Ruby, Python, Java, C#, or any other language.
A C program that accesses the memory will do so in an extremely predictable way, if I lay out a memory structure, a piece of code and an access pattern then I can be very sure about how that will interact with things like the caches.
In other languages where there is more 'under the hood' that is a lot harder.
Libraries don't enter in to the problem, that's another level altogether.
While it's true that library code written by third parties might be less (or more) efficient than the code you wrote, even those libraries will have the luggage of the underlying implementation of the language.
In C there is no implementation underneath, it is a 1:1 correspondence with machine instructions.
That is the reason that kernel code tends to be written in C.
I think my point is that you can lose track of the woods for all the trees; moreover, C is not actually a good map with the underlying hardware.
In C, you deal with so many trees, it sure feels like you're right there in the woods. But actually, if you're dealing with things on a tree by tree basis, you're not getting much done. And you can pretty lose your way by focusing on navigating territory efficiently at that level, but not keeping track of the overall goal.
As to whether kernel code should be written in C, that is a different matter. C is not a good map to von Neumann architectures because it doesn't model shared code and data in memory - C doesn't have a good representation for writing code at runtime. Most code written in C will not be the most efficient possible code for this reason.
Don't you just love drive-by readers who downvote all your comments in a thread, and never leave a reply indicating why they disagree with you? Because I sure do...
Sure, portable assembly language. With, you know, named variables, type abstraction, recursive function decomposition, infix expression grammar, heirarchical flow control constructs... just a bunch of silly tricks. :)
Modern developers have gotten so used to the fact that C is "low level" that they tend to forget how low really low level coding is. There's a ton of "high level" language features in every 3GL, and that includes C. The abstractive distance from machine code to a language like C or Pascal is far, far higher than it is between C and Python.
One of the odd things about C, historically speaking, is actually how impoverished it was compared to macro assemblers written at around the same time. Those didn't have much of a type system either, but you could get all kinds of power with them. No modern assembler is really comparable, much to my dismay.
The comment was probably referring to things like "copying stuff is expensive" or "function calls are expensive", not more specific details of the machine you run on. In C++ you use pointers/references to solve the first problem, and define header-only classes for the latter. Even if you weren't aware, basic use of the the standard library will clue you in.
i don't even know on what kind of hardware my java or python programs run. neither google (appengine) nor our IT apartment tell me.
so for most app developers "a computer" is not really something they work with. of course someone must write those abstractions (python, etc), and they do it in C/C++ :)