| I am not an expert in functional languages, but I reason about it (that is, the question "Are FP languages inherently slow?", not the article) in the following way. I am curious to know if this reasoning is, well, reasonable. - 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. |