3 ms·
> It's the lowest level you can be, while still providing the HL constructs we're all used to. I disagree completely. A language much better than C will come a
by versteegen 10y ago
> It's the lowest level you can be, while still providing the HL constructs we're all used to.
I disagree completely. A language much better than C will come along in its niche, and I'll be switching.
C isn't low level enough. It has too much undefined behaviour (and tries to be too portable), each instance of which denies you access to real machine behaviour. Signed ints don't even wrap around! Effectively, C does not even support twos-complement signed integers, as exist on all modern computers since decades ago, without a special compiler flag! You have to resort to tonnes of compiler-specific extensions to get things like leading-zero-count, SIMD, and computed-goto. Even with GCC's zillion extensions that were added for people who have to do really low level work, C is still hopeless for writing maximum-performance VMs, that's why Mike Pall wrote the LuaJIT2 interpreters (one for each architecture) in assembly. Here's one of his explanations why C shouldn't be used for such a thing [1]. I've also tried writing a high performance interpreter in C, and I found that I wasted 80% of my time trying to get the C compiler to output the sequence of instructions I wanted. Next time, maybe I'll just use assembly and save myself a lot of trouble.
Secondly, C is not high-level enough. A low level language like C needs a powerful macro system to let you abstract away the details of your object system or whatever. C's preprocessor has many flaws [2] and is one of the worst in existence. A good macro facility allows compile-time generation of code in a readable (or at least type safe) way, like D and Lisp do. C and C++ users don't realise they have the preprocessor equivalent of a Blub language [3]. Sure, C++ is an extension of C with high-level features, and was a good attempt, but it's too complex and C++'s template meta-programming just about the only compile-time codegen solution worse than C's preprocessor.
[1] https://web.archive.org/web/20160209102431/http://article.gmane.org/gmane.comp.lang.lua.general/75426 https://web.archive.org/web/20160209102431/http://article.gm...
[2] Read any rant, e.g. http://c2.com/cgi/wiki?CeePreprocessor http://c2.com/cgi/wiki?CeePreprocessor
[3] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- qwertyuiop924 10y agoYes, C's preprocessor is weak, but that's a quality of life thing, not a necessity by any stretch. And as for C not being low-level enough, that was my point - C is as low level as you can be, before you become unportable.
- naasking 10y ago> And as for C not being low-level enough, that was my point - C is as low level as you can be, before you become unportable. I don't think that's true. You can add first-class support for bitdata [1], much better than C's bit flags and portable, better support for alignment declarations, better/safer support for absolute addresses, native SIMD-like vectors [2], exposing arithmetic carry flags, and more without losing portability. [1] http://web.cecs.pdx.edu/~mpj/pubs/bitdata-icfp05.pdf http://web.cecs.pdx.edu/~mpj/pubs/bitdata-icfp05.pdf [2] https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
- qwertyuiop924 10y agoWell, now we know what to ask for in C17.