> [...] We lose all information when the program crashes [...] Ah, what you wrote earlier makes sense in light of this :) > In C, you sacrifice safety (undefi

> [...] We lose all information when the program crashes [...] Ah, what you wrote earlier makes sense in light of this :) > In C, you sacrifice safety (undefined behaviour etc.) for speed.[...] You can write slow code in any language, a program isn't necessarily fast because it's been written in C. It's fast because it's been written with runtime efficiency in mind. Undefined behaviour comes from not making unnecessary assumptions on the underlying platform, which aids portability. > But has a minimum of three times the memory overhead.[...]C sacrifices safety for speed and memory efficiency Memory efficiency, yes. I, for one, prefer not to rely on a garbage collector and verify correctness with valgrind. You do have to diligently manage memory, or any language that assumes GC may win in the long run. Speed, however, was never a goal of C. You could argue the same thing with assembly, if you do all of the hard work yourself the result can be faster and more efficient than the same application in C. Neither was meant to be fast or efficient on its own, but may be considered as such when compared to higher level languages. > There is a JVM for mips isn't there? It exists, but it's proprietary. > Or don't you have enough memory? Not by a long shot, usually. > JVM languages uses alot more memory than a native program, that doesn't necessarily make JVM-based languages any less portable. Not on principle, but in practise it does. > The same .jar file can be executed on Windows, Linux, Mac and more operating systems without a recompile. [...] I'd argue that they are more portable than C. You simply moved the problem from the program itself to the underlying platform. By that logic, I can prove a PPC binary is portable by running it in qemu on x86. As long as there's a PPC or Java bytecode implementation, the hypothetical programs will work. Fact remains that given Java or C source code, the C code will end up being more portable. > Last but not least, it's important to use the right tool for the right job. I would never write a VM in a JVM-based language [...] never write a GUI application in C. I absolutely agree with using the right tool for the job, so never say never. Both examples can be perfectly reasonable ways to get a certain job done, we just don't see them very often.