Loops are a general purpose device that must be specialized for a given use case - e.g. map, reduce, fold et cetera. Programmers often get the details wrong when implementing such use cases. In a functional program, each use case is named and generally available (in a correct form) via a library or built-in operation.
Ask HN: Why do functional programmers hate loops (for, while, etc.)?
11–20 of 73 posts
Re: Ask HN: Why do functional programmers hate loops (for, while, etc.)?
#12Ah, i hate those coding styles where everything must use forEach/map/reduce
Re: Ask HN: Why do functional programmers hate loops (for, while, etc.)?
#13Well, how to calculate sum from 1 to 5000 ? Instead of looping from 1 to 5000, you define the relationship instead: sum(1,n) = 1 + n + sum(2, n-1). Isn't this clearer to understand problem first, instead of just looping ?
do people really think this is clearer than looping.. my mind immediately goes to a loop here
Re: Ask HN: Why do functional programmers hate loops (for, while, etc.)?
#14Loops have the potential to be very inefficient. As an exercise you can write two scripts in Javascript, one that has a for loop and another that does the same thing functionally. Then you can use Node to dump the VM instructions. You might be surprised at how many fewer instructions the functional version requires.
Re: Ask HN: Why do functional programmers hate loops (for, while, etc.)?
#15Well, how to calculate sum from 1 to 5000 ? Instead of looping from 1 to 5000, you define the relationship instead: sum(1,n) = 1 + n + sum(2, n-1). Isn't this clearer to understand problem first, instead of just looping ?
It's a very clear infinite recursion at best, and a buggy definition for odd `n` if that's fixed. I wouldn't imagine making either error if just looping...
Re: Ask HN: Why do functional programmers hate loops (for, while, etc.)?
#16Ah, i hate those coding styles where everything must use forEach/map/reduce
forEach is still a loop
Re: Ask HN: Why do functional programmers hate loops (for, while, etc.)?
#17Well, how to calculate sum from 1 to 5000 ? Instead of looping from 1 to 5000, you define the relationship instead: sum(1,n) = 1 + n + sum(2, n-1). Isn't this clearer to understand problem first, instead of just looping ?
IMHO: no.
The concept of a loop (i.e. doing something over and over as long as a condition is true) is (again IMHO) a much simpler concept than recursion.
The university I worked at tried moving functional programming into the first semester. Let's just say, that didn't work out at all. The imperative programming style is apparently much easier for students to grasp.
Edit: The more I think about it, it seems to me that a loop is clearer because the initial state, upon which you iterate on, is much more obvious. Where with recursion, I primarily see the step, but not where exactly I started from -- if that makes any sense..
Re: Ask HN: Why do functional programmers hate loops (for, while, etc.)?
#18Well, how to calculate sum from 1 to 5000 ? Instead of looping from 1 to 5000, you define the relationship instead: sum(1,n) = 1 + n + sum(2, n-1). Isn't this clearer to understand problem first, instead of just looping ?
Well, how to calculate sum from 1 to 5000 ?
Instead of looping from 1 to 5000, you compute (1 + 5000) * 5000 / 2
This is what "understand problem first" actually means
Re: Ask HN: Why do functional programmers hate loops (for, while, etc.)?
#19Ah, i hate those coding styles where everything must use forEach/map/reduce
forEach is still a loop
The functional programmers (in my circle) have latched on to forEach/map/reduce/filter etc as the bibile of functional programming. Writing a simple for..each loop will make them reject PRs
Re: Ask HN: Why do functional programmers hate loops (for, while, etc.)?
#20Be very careful with "why do X hate Y?" Generally speaking, if someone comes out as outright hating Y, their opinion should be taken with a pound of salt. Functional programming is fundamentally at odds with imperative constructs. It's not that people hate them, it's that they generally just don't fit the paradigm of "build a pipeline of steps (functions) and feed data into it" as well. Most of my software is functio…
>"build a pipeline and feed data into it."
Arrows in Haskell are actually pretty good at building functional left to right data processing pipelines.