31–40 of 73 posts
But going further, many loops are actually maps, where you do something independently with each element of a list. Why formulate that as a linear visit to each element?
Be 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.
functional programmers are kind of like cargo bike riders. they know they can solve their problem otherwise and in a much simpler fashion but insist on riding the cargo bike.
Cargo bikes don't get stuck in traffic; functional programmers don't like getting stuck debugging.
Cargo bikes are easy to park; functional programs are easy to run in a REPL.
...and so on.
The latter is declarative and more expressive and when you compose these pieces, you express your code at a higher level of abstraction as a whole. Maintainability, fewer scope for bugs etc.
Well, 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 ?
2. Composition: If the loops don't mutate there are functional alternatives (map, reduce/fold, filter, etc) which are composable.
3. Abstraction: Loops are traversal instruments. Sophisticated functional languages / environments have some mechanism for generalizing traversal of any data structure into a higher order function or some form of reusable generalization.
That said, I use a lot of loops in library code for performance and expose functional interfaces for consumers.
It's about what conveys the intent most clearly.
What do you prefer?
``` let sum = 0; for (let elem of array) { sum += elem.value } return sum ```
Or
``` Math.sum(...array.map(elem => elem.value)) ```
What about
``` let parent = document.createElement("div") for (let user of users) { let userElem = renderUser(user) parent.appendChild(userElem) } return parent ```
vs
``` let parent = document.createElement("div") parent.appendChild(...users.map(renderUser)) ``` vs ``` {users.map(user => )} ```
functional programmers are kind of like cargo bike riders. they know they can solve their problem otherwise and in a much simpler fashion but insist on riding the cargo bike.
Nothing beats fitting a week of groceries on your bike, though.
The usual way to turn them into smaller problems is induction and the easiest way to turn inductive reasoning into code is to write recursive code