Indeed. I would also add GPU programming, and also a number of features of modern processors such as hardware STM and some other such things tend to be things that C supports only poorly or as an afterthought, despite the fact Intel generally has to keep C compatibility in mind as a design criterion in the first place, an advantage shared by virtually no other language. (Perhaps C++.) It has also long had the "aliasing" problem which is the reason Fortran kept its position as a math language for so long.
Of course in each case, C has been extended so as to do "something" with those features. (Excepting GPU programming, which is just such a different abstraction that C just stops working entirely.) But they are extensions bolted on after the fact, to varying degrees, not something well-integrated into the core language and its core runtime, which remains an abstraction of the 1970s computers from which it emerges.
Which is, all things considered, not that great a criticism, seeing as how few modern languages are terribly optimized for these cases either. The very cutting edge of general-purpose languages today are arguably focused for hardware now merely 10 years old. It doesn't mean I think C is "bad" (... or, at least these reasons aren't related to my real objections). It just means that C, while a great guide to how computers worked 40 years ago, is not all that great for the much richer and more interesting machines of today.
I suppose one can make a solid argument for teaching the 1970s model as a valid simplification. Still, I'd prefer that professionals see it as such, rather than have the unexamined idea that C is truly "how computers work".
> Indeed. I would also add GPU programming, and also a number of features of modern processors such as hardware STM and some other such things tend to be things that C supports only poorly or as an afterthought, despite the fact Intel generally has to keep C compatibility in mind as a design criterion in the first place, an advantage shared by virtually no other language. (Perhaps C++.) It has also long had the "aliasing" problem which is the reason Fortran kept its position as a math language for so long.
There is a lot wrong with this paragraph.
1) The comment I replied to mentioned CPUs
2) the "S" in STM is software, "hardware STM" is a misnomer, it is rather "Transactional Memory" and isn't a particularly modern feature. Hardware designers have dabbled in it for decades, and I don't think it's particularly more popular today than previously
3) C89 already had fairly strict aliasing rules that systems programmers hate so much that every modern compiler has a flag to disable it. Furthermore C99 added the restrict keyword which eliminates this problem (though yes, the motivation for not including "restrict" in C89 was braindead.
> Which is, all things considered, not that great a criticism, seeing as how few modern languages are terribly optimized for these cases either.
This is true with a but; it's true in the extent that it's not like C gets it worse than the average high-level language, but the current selling point for C is that it's "close to the hardware" or "portable assembly" and the less that is true, the less strong C is.
In this meaning I don't consider the statement correct.I don't know a language which is closer to the machine.
Assembly does not count, because it is not a single language. Multicore is mostly a library issue and C11 is as close to the machine as any other language here. There are languages aiming at distributed programming (Erlang,X10), but none of them claims "close to the machine". SIMD is bolted on in C, but no other language does better. Caches are supposed to be transparent; Are there languages with explicit support for scratchpad memory?
This leaves GPUs. OpenCL is supposed to be the solution here. Would you consider OpenCL closer to the machine than C?
