3 ms·

I agree. But this is a misconception about functional programming in general, that its purpose is to somehow replace imperative actions that are done by the com

by js8 10y ago

I agree. But this is a misconception about functional programming in general, that its purpose is to somehow replace imperative actions that are done by the computer system with something else which is not imperative. But that's not the goal. Functional programming is there to provide a better formalism for writing programs, it doesn't want to change the way the computers actually execute the programs (or how the systems eventually internally work). That means more work for the compilers to figure out how to make the same old imperative program out of a functional one, which is a good thing (it's generally the direction the compilers evolve). Benefits of functional programming are not in how programs are executed (quite to the contrary - it's actually more effort to make them as efficient as good imperative programs), but in how the programs are written by people. I think the article is a little confused about this. For another example to see this, even notion of non-pure function goes already in this direction. Today, having lots of (small) functions seems to have negligible downsides, but historically this wasn't the case at all, look at any better program that had to fit into memory of an 8-bit computer. These were rarely written in this style, because compilers were simply not capable enough to produce a reasonably compact spaghetti machine code out of those (by means of inlining, for instance).

wott 10y ago
To sum up: harder to write, harder to compile, harder to make efficient. Hum... difficult to qualify it as 'better' after this.
- js8 10y ago
  I agree with you. Yet, strangely enough, it is better. Maybe we could say, easier to read, easier to modify, easier to reuse? Let me return to that last example. Take a program written in procedural style, and an identical program written in a big ball of mud style (all variables are global, one big control flow). This is a discussion from like 1960s. It's harder to write for human, and harder for compiler to compile and make efficient program in procedural style. Yet, I am sure today, you would prefer procedural style. It makes sense (trust me, I actually work with big-ball-of-mud programs written 30+ years ago at work, AMA). I don't care what work the compiler has to do, I care about my own time. Functional programming is just another step on that road. As a side note, I really think people who prefer FP should avoid (over)selling it as more computationally efficient approach, because it still isn't (even though it probably will be in the future). It's a little bit of optimistic dishonesty that IMHO hurts adoption of FP and feeds the misconception that I talk about.
- marcosdumay 10y ago
  Harder to make errors, easier to modify. But what you said is true too.

by js8 10y ago

wott 10y ago

To sum up: harder to write, harder to compile, harder to make efficient. Hum... difficult to qualify it as 'better' after this.

js8 10y ago
I agree with you. Yet, strangely enough, it is better. Maybe we could say, easier to read, easier to modify, easier to reuse? Let me return to that last example. Take a program written in procedural style, and an identical program written in a big ball of mud style (all variables are global, one big control flow). This is a discussion from like 1960s. It's harder to write for human, and harder for compiler to compile and make efficient program in procedural style. Yet, I am sure today, you would prefer procedural style. It makes sense (trust me, I actually work with big-ball-of-mud programs written 30+ years ago at work, AMA). I don't care what work the compiler has to do, I care about my own time. Functional programming is just another step on that road. As a side note, I really think people who prefer FP should avoid (over)selling it as more computationally efficient approach, because it still isn't (even though it probably will be in the future). It's a little bit of optimistic dishonesty that IMHO hurts adoption of FP and feeds the misconception that I talk about.
marcosdumay 10y ago
Harder to make errors, easier to modify. But what you said is true too.