>>65
Not the slightest. Actually, as far as the current development in C is, C has no 'point' to be missed. At all. C has no clear objective. C is used for both kernel development and GUI applications in an almost promiscuous relationship -- one including headers from the other, for example.
C cannot be called a portable assembler -- it does not make sense, at the very best. C compiles _very badly_ at the assembly level. Current C compilers have pitiful support for SSE or vector instructions; many C compilers lack LTO (Link-Time Optimization), which outperforms intra-procedural optimization in large scale. Some compilers can't even figure out extremely simple assembly-level constructs, due to a variety of factors; for example, I've never seen a single REP SCAS sequence being yielded (outside a builtin call) from a single scan loop, or even some register being used _properly_ inside a specific context in which it was created to be used in the first place. Advocates of the idea that C compilers optimize code better probably haven't ever written a single line of assembly, or haven't done it seriously yet. Even the C function call model (using the stack to push arguments) has directed the hardware industry to heavily optimize the stack access at the hardware level, simply because most compilers couldn't agree on any standard means to transport metadata about such calls at the toolchain level (for example, re-using registers and flags as parameters), a thing any competent assembly programmer would know how to do. Some aspects of modern hardware aren't even reflected on C constructs, and kludges emerge. For example, the need of memory fencing to synchronize cores in an SMP processor can't be foreseen by the compiler analysis, thus the need of hardly inserting such instructions on every call to a pthread function to guarantee correct behavior.
I agree, though, that these problems are not more related to the language than they are to the _implementations_. Nevertheless what matters, in practice, is _practice_, not theory. It is always possible to create a frontend abridging the least common denominator from a set of architectures, thereby yielding correct code for every one of them from the same source file, but claiming that such design is a 'portable assembler' can hardly be sustained, in my opinion.
Last, but not least, this is not about 'what I want'. It is not a personal relation with the matter. It is about 'what the thing really is'. I have had a sane-as-possible relationship with C for about ten years now, but that should not impede me to see what it really _is_, instead of seeing what I _wanted it to be_. Ultimately, as I said, choosing C for any reason is merely circumstantial, due to the current state of affairs of modern technology. No one gives a fuck whether the PHADDW is being properly used for maximum performance on your shiny new Wolfdale core, or whether the crash will occur on the next input byte from the socket. The big issue is whether these things will generate new sales or not: new compiler sales, new standard document sales, new processor chip sales. The corretude is actually the most inconvenient part of the process. C has done its grand part on helping library developers sell their crap, helping hardware developers sell overpowered processors, and helping specialized consultants to help clear all the derived mess up.