3 ms·

It's usually better to do the right things slowly than the wrong things quickly. In practice most speed improvements are made by improving the algorithm. Wit

It's usually better to do the right things slowly than the wrong things quickly. In practice most speed improvements are made by improving the algorithm. With high level languages, you can do this faster. C still uses malloc and free, functional programs which don't dynamically allocate memory won't call the garbage collector, and there are fast garbage collection algorithms for the ones which do. Functional languages aren't intrisincally slow either. Strong static typing/type inference allows them to be compiled to very fast code.

kbwt 9y ago
There is software which is already so optimized at the algorithm level, you have to use a low level language to fully exploit the hardware. For example with video games; if you can cram more/better content or achieve higher simulation fidelity/tickrate you improve the game experience and developers compete on that. These are programs where selecting a different instruction to split a loop-carried dependency makes a significant difference. Data is carefully packed and reorganized between passes to optimally match the cache hierarchy. Good luck selling these developers uncontrollable per-access indirections and thunks. Furthermore, this kind of code barely uses malloc/free, preferring instead to use custom allocation patterns tailored for each use case. If you replicate that in a higher level language, you effectively do your own memory management within a large block allocated by the runtime. So you are liable to write all of the same lifetime/indexing bugs in while using your shiny "safe" language.