who said C is simple? :S
After looking at the JavaScript/ECMAscript standard, or even C++, C feels positively trivial in comparison.
Who Says C is Simple? (2010)
31–40 of 59 posts
Re: Who Says C is Simple? (2010)
#32C is simple to compile into nearly-optimal code, or at least it was back in the 1970s, when computers had single-opcode dispatch or trivial pipelines, no SIMD hardware, no other parallelism worth mentioning, and it wasn't worth worrying about cache too much. (Running in the registers was a neater trick.) That meant it was relatively simple to 'see' the assembly language 'behind' a given C function or stretch of code;…
"C is simple to compile into nearly-optimal code, or at least it was back in the 1970s,"
And yet the best practice of the time was not to use C for time-critical applications. If your hypothesis were true, why would, say, all those NES programmers write all that assembly?
Re: Who Says C is Simple? (2010)
#33C is simple to compile into nearly-optimal code, or at least it was back in the 1970s, when computers had single-opcode dispatch or trivial pipelines, no SIMD hardware, no other parallelism worth mentioning, and it wasn't worth worrying about cache too much. (Running in the registers was a neater trick.) That meant it was relatively simple to 'see' the assembly language 'behind' a given C function or stretch of code;…
I honestly think people like you just troll, making outrageously incorrect statements just so naive but technically knowledgeable people will comment, correcting you. It's an insidious way to gain technical answers that costs little effort that I have been seeing more and more of lately.
Re: Who Says C is Simple? (2010)
#34C is simple to compile into nearly-optimal code, or at least it was back in the 1970s, when computers had single-opcode dispatch or trivial pipelines, no SIMD hardware, no other parallelism worth mentioning, and it wasn't worth worrying about cache too much. (Running in the registers was a neater trick.) That meant it was relatively simple to 'see' the assembly language 'behind' a given C function or stretch of code;…
But everything that came after C hasn't improved on this, at all. In fact, languages now dominate that aren't compiled. So as it stands, C is still your best bet when you are looking for that optimal translation. Intel has recently made some effort to augment it in ways to fully utilize new CPUs various parallel pipelines and specific functionality: https://ispc.github.io/
ISPC is cool, what it helps out with (writing the SIMD kernel) has never really been the bottleneck in my experience.
The data still has to be arranged optimally for the hardware in order for SIMD code to have any benefit (and at this point, writing SIMD code is straightforward). You also still need to be experienced with the capabilities of the hardware if you have any chance of writing good ISPC code (although this is true of C, as well as any shading language).
That said, using it to target SSE and AVX with the same code is attractive.
Re: Who Says C is Simple? (2010)
#35who said C is simple? :S
[deleted]
Re: Who Says C is Simple? (2010)
#36All of the examples here are really horrible code. This is the second article in a few days on Hacker News to list out a few examples of how hard C is. And for little reason; there's absolutely no value in being able to write something like:
return ({goto L; 0;}) && ({L: 5;});
So why are we still writing code like this?
The answer is reverse compatibility. Not just of compilers, but of tools and skillsets: people are unwilling to support multiple versions of C and want their code to run forever.
Objective-C and C++ do things to add functionality to C, but they don't remove the functionality of C that allows these kinds of problems.
This points to a need for a new language that avoids these issues. I think Rust is the answer, but I would like to see more languages try to fill that gap--competition is healthy.
Re: Who Says C is Simple? (2010)
#37Earlier quoted context omitted.
Depends on how you define simple: If something is simple for the compiler-writer, then simple things do yield simple results. If something is simple for the programmer, simple things often yield quite complex results. For example, in a language that's simple for the compiler-writer, (1/10) times 10 is only very rarely 1. 0 is a common answer, as is some fraction which is almost, but not completely, unlike 1. In a lan…
It really only depends on if you define simple as "can only derive simple results." And, you do realize that one of the simplest languages for compiler writers, lisp, doesn't have to move heaven/earth to make that calculation work out how you want it.
> And, you do realize that one of the simplest languages for compiler writers, lisp, doesn't have to move heaven/earth to make that calculation work out how you want it.
I've written a C compiler and am currently writing a Lisp compiler, and I'm not sure where you get the idea that Lisp is a simple language for compiler writers. Lisp's simple representation belies a very complicated runtime, to the point that the majority of Lisp implementations don't support compilation at all--they're interpreted only.
Re: Who Says C is Simple? (2010)
#38I've been looking for this for months, I wanted to link this to my friend who said he prefers C to Java for his CS classes.
Re: Who Says C is Simple? (2010)
#39I stopped reading after the explanations about return ((1 - sizeof(int)) >> 32);
Unless size_t is wider than 32 bits, it has undefined behavior. That's why it returns 0; it could as well be 42, or the program could terminate with or without a diagnostic message, etc.
Re: Who Says C is Simple? (2010)
#40I've been looking for this for months, I wanted to link this to my friend who said he prefers C to Java for his CS classes.
Come on, almost any language I can think of is a better fit for CS classes than Java.