Ask HN: Why do functional programmers hate loops (for, while, etc.)?

Have you used tail|head in any language. To them it seems more elegant and a "better" way of doing things.

I guess looping constructs have some kind of states and functional paradigm, as I understand it, avoids them.

To some extent for while loops are a matter of taste. But the issue is that unless you have mutable variables, you cannot use typical imperative control variables.

So something like:

  bool done = false;
  while (!done) {
     ...
  }

makes no sense unless you have some way of setting `done = true`; which is not possible in purely functional languages like Haskell.

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.

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 ?

    sum(n) = is_even(n) ? n/2 * (n+1) : (n+1)/2 * n

  sum(0) = 0
  when n != 0: sum(n) = n + sum(n-1) 

    sum(n, acc=0) = n == 0 ? acc : sum(n-1, acc+1)

    acc = 0
    for i = 1 to n
        acc += 1

For some people, thinking in "functions" makes more sense than thinking in "algorithms".

The former prefers a "declaration" of THE state. for/while loops imply a change of state, so they're a big no here.

The latter prefers an "imperative set of steps" to go from initial state to the desired state. for/while loops make the "steps" easier here.

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 functional, but you will find the occasional C-style loop, especially if the map/filter/reduce alternative is ridiculously complicated to read.

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.

Ah, i hate those coding styles where everything must use forEach/map/reduce

Loops 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.

Fpers, lispers, tdders, clean coders, etc

There are many religions in programming world

Just get familiar with them, take what is sane and avoid the rest

Extremas are rarely the best

Using a map or a reduce instead of a for-loop feels like using a foreach instead of a while-loop.

Once these came naturally, doing anything else starts to feel underconstrained and imprecise.

most functional techniques wrap walking a loop into a few functions, like fold. writing loop constructs can be error prone. one is much less liable to make a mistake passing in an array into a function and have it processed using another function. idea being separation of logic. why care about loops when one only thinks in arrays and streams being processed? i don't think i've written a for loop in js in a couple years at this point with the help of libraries like ramda.

oh and loops constructs are not composable...

In theory, purely functional programming is declarative in nature - there are things you can tell about the state of the program just from reading the code, whereas in imperative programming (with loops and changing state) you can't tell with confidence what the state of the program will be without running it. There's a certain appeal to the declarative flavour that I used to care a lot about and somehow managed to forget to care about. FWIW I can't say that my programs became worse when I forgot to care about purity. But there may be some scenarios and domains where this sort of confidence can make a difference, and I just happen to not work often in these areas.

I think one problem is that some of the syntax doesn't express what you are trying to do, it's just low level mechanism, especially C for loops for example.

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?

Looping constructs - How it is done. Functional - What is done.

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.

1. Immutability: Functions are expressions that return a singular value without mutating state. Most loops are not expressions and have some mutation happening.

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.

Not all FP programmers hate them, I use them in a pinch.

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 ``` <div> {users.map(user => <User {user} />)} </div> ```

Problems are generally easier to deal with if you can turn them into smaller problems.

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

It's kind of silly IMHO. Recursion has plenty of "state", it's added on the stack before each function call. So under the hood it's all stateful. But instead of e.g. a nice simple counter variable, you've got an ever growing pile of stack frames - with hopefully some compiler shenanigans to eliminate them and convert it to a counter internally.

Functional languages use recursion instead of for and while loops. Recursion is a more general mechanism that can be used to implement the equivalent of for and while loops.

So in short, functional programmers do not "hate" looping construct, but simply don't need them since you can use recursion instead (in practice you actually rarely use recursion directly, but instead use functions like map, fold, sum, etc. which are implemented recursively).

The point is not about ignoring them; the point is about using a construction with higher semantics.

A loop is a label+goto in disguise. You have to look at what's inside to understand what the loop is doing; you can't get a global sense of how it is impacting data without looking at what it actually does.

In functional programming, loops are replaced by constructs such as foreach, reduce, map or filter, to indicate right away how the body of the loop operate on the data it is scanning. It enables a functional approach to looping, where one first thinks about how data are transformed -- about the functions to apply on items and what is the overall output of the loop.

The rule of thumb I use is if something has side effects, I use a for loop. If it doesn't, I use whatever functional constructs the language gives me. They're obviously equivalent approaches, but the choice provides some semantics to people reading the code: look carefully at for loops for side effects.

What's interesting is that you start to see less need for side effects in most cases. Still some, but a lot less than you'd think.

It's the fundamental difference between declarative and imperative programming.

Loops conflate two different questions: "what do you want?" and "how do you want it done?" If I write (Haskell):

    map (+1) list_of_numbers

I have expressed only that I want one added to every number in a list. Whereas if I write (C):

    for (size_t i = 0; i < sizeof(array_of_numbers); i++) array_of_numbers[i]++;

I have expressed both that I want one added to every number in the array and I have also described exactly how to do it, including the order I want it done in.

So what's the big deal? On the one hand, the imperative approach gives me more control. On the other hand, I may not want that control! Perhaps I don't care what order the numbers are incremented in, I just want it done, and the extra details in the for loop are just "line noise" which gets in the way of being able to quickly read the code and understand what it does.

There are other factors, of course. One advantage to the functional approach is that the library author who supplies map (since it's not built-in to the language) is free to change the details under the covers. Perhaps they find a clever way to parallelize the implementation, then all of my code which uses map gets a free speed-up! Now, there may be other reasons why this won't work in practice (to do with legacy code, of course) but the principle is sound!