3 ms·

If you consider performance as a correctness issue, then functional and/or garbage collected languages have a very high incidence of bugs.

• DonaldFisk 9y ago
  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.
• qwerty456127 9y ago
  Theoretically this can be true. I.e. you can write anything (good or bad, correct of quirky, fast or slow) adequate to your skills in C so being proficient enough you can potentially end up with a C program that would solve the same task faster than a functional/mixed program in Scala. In practice, however, real-world Scala programs usually run approximately as fast (or faster) than real programs real humans write in C as far as I know (and can be developed/modified much faster). And they are less prone to crash, expose a vulnerabilities, produce wrong results or have portability problems. But they indeed tend to require a way more memory than you would probably fit in if you'd go the old-school way using manual memory management, sharing and re-using memory regions as much as possible.