> It really does only do what you ask it to; nothing more, nothing less.
Not even assembly language has this property anymore, especially in the presence of an OS.
Which leads me to what I think is C's greatest weakness: It's no longer a thin layer over assembly language. It is so far removed from the current trends hardware design it doesn't even have functions that implement memory barriers as part of the core language, let alone any language features to help you take advantage of whatever SIMD hardware the machine possesses.
Part of this is C becoming a victim of its own success: People expect the same language to compile down to ARM and x86-64 and IBM mainframe (zSeries) and so on and so forth machine code, and do it in an efficient manner. Since low-end ARM chips don't have SIMD, C can't have SIMD, the thinking goes (even though low-end hardware doesn't have FP opcodes, either, but floating-point math is still part of the C standard).
They rely on compilers to make it fast, which is reasonable to some extent but it's also the same thing you rely on when you write in Haskell. It's contrary to the spirit of things.
I'm not advocating a return to assembly language. That would be massively stupid. However, it would be nice to have a language with concise syntax that also allows you access to the processor's status word (the carry flag, for instance).
There's nothing in the "Python way" that precludes dropping into C as and when it makes sense to do so. A C programmer is able to make that decision independently.
Not even assembly language has this property anymore, especially in the presence of an OS.
Which leads me to what I think is C's greatest weakness: It's no longer a thin layer over assembly language. It is so far removed from the current trends hardware design it doesn't even have functions that implement memory barriers as part of the core language, let alone any language features to help you take advantage of whatever SIMD hardware the machine possesses.
Part of this is C becoming a victim of its own success: People expect the same language to compile down to ARM and x86-64 and IBM mainframe (zSeries) and so on and so forth machine code, and do it in an efficient manner. Since low-end ARM chips don't have SIMD, C can't have SIMD, the thinking goes (even though low-end hardware doesn't have FP opcodes, either, but floating-point math is still part of the C standard).
They rely on compilers to make it fast, which is reasonable to some extent but it's also the same thing you rely on when you write in Haskell. It's contrary to the spirit of things.
I'm not advocating a return to assembly language. That would be massively stupid. However, it would be nice to have a language with concise syntax that also allows you access to the processor's status word (the carry flag, for instance).