> It would take you months to do that in assembler, and half a day to do it in C.
Imprecise. If considering only a specific platform and no existing libraries, you're even completely wrong: Coding ASM is significantly more time-consuming than coding C, but the difference is 3-5 times "only".
Obviously, with C, you get a higher level of abstraction, therefore more reusability, portability, etc.
> Then the C code would end up faster because compiler optimizations are faster than anything a person could hope to do,
Depends on the platform. Hardly anybody is able to optimize for speed a modern x86 processor "by hand", but RISCs and even some CISCs like the 68000 are another story. I have been programming for years as a hobby on the 68000 processor, and I have seen:
* GCC missing completely obvious CSEs: a global array used about ten times in a row, the compiler won't put its address into a register even if it has many spare ones;
* GCC not using the instruction set possibilities (10-byte code instead of 4-byte code, and that spills one more register; bad code related to local variables on the stack; etc.);
* GCC completely messing up a calling convention that should be more optimized ( saves&restores on a register that isn't even changed);
* etc.
Wonder why a number of not-very-powerful embedded platforms, like calculators, are still partly programmed in ASM...
There may be more appropriate compilers for those processors, but hey, GCC is supposed to be portable, and it has (had, they deprecated some useful things like casts-as-lvalues in GCC 4.0) cool extensions that most other compilers don't have.
> and it would be portable too.
If you use external libraries like the SDL, yes. Otherwise, no, not more than ASM.
