Re:Are functional languages inherently slow?
by slurgfest on Thursday July 26, 2012 @02:45PM
(#4297860)
It just seems funny to have an argument between the user having to use the machine's phrasing vs. having to use the phrasing of higher math. Higher math is clearly not the only abstraction. Ergonomics for one person coding or for two people collaborating, on a practical task, seem more important to me.
- CPUs are inherently not functional. They are imperative, as they are Turing machines. They don't speak high-level math.
- Therefore, programs written in a functional language must always be translated into imperative code for execution. Compare this with an imperative language where the compiler need not perform super-fancy translation.
- If the problem can be mapped efficiently to machine code by the compiler, the functional program is fast; otherwise, it may be slow. Either way, it may be very hard to know what is going on behind the scenes.
- This is not always a lose; sometimes the compiler can perform extensive optimizations because it speaks math, and the functional language will win handily.
- Writing in an imperative language, you always know how your program will behave; however, you lose the opportunity to have the compiler deduce a better way (assuming there is a better way) by writing in a functional language.
- But if there is no better way, you have the opportunity to make the execution very fast by modeling the imperative solution around the constraints of the hardware.
Of course, there are other dimensions to performance, among them programmer productivity and number of defects.