Ask HN: Why do functional programmers hate loops (for, while, 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 ?

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

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.

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

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.

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!

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.

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

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.

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.

In functional programming, we value immutability and the notion of pure functions, meaning their outputs depend solely on their inputs without any side-effects. This is one of the reasons why we often lean away from traditional loop constructs of imperative languages, which are typically stateful and can produce side effects.

Instead of using loops, we often use higher-level functions like map, filter, and reduce. These functions allow us to focus more on the "what" (the operation being performed) rather than the "how" (the control flow). It's like saying, "transform each item in this list," as opposed to, "start here, do this to each item until you get to the end."

And when we do need to perform repetitive operations, we tend to use recursion rather than loops. Recursive solutions don't require mutable state and are easier to reason about, especially when the logic gets complex.

Lastly, mutable state, which is common in loops, can lead to issues such as race conditions in multithreading or distributed computation environments. The minimized state changes in functional programming makes it often more suitable for these scenarios.

So, it's not really about "hating" loops, but more about choosing the constructs that align better with the philosophy and goals of the functional paradigm.

To conclude, In order to use imperative looping constructs, you have to violate referential transparency and immutability, which are the hallmarks of functional programming.

https://en.wikipedia.org/wiki/Referential_transparency?usesk...

https://en.wikipedia.org/w/index.php?title=Immutable_object&...

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.

In JS, functions like filter/map/reduce can help when you try to write immutable code because you only work with the arguments, and return an output value. You don't have to define an empty/temporary array first, and fill it up in your regular for-loop for example.

I don't 'hate' loops, I still use them sometimes. Personally I just try to avoid them (in JS) because I feel like I can solve my problem without any side-effects. It's something less to think about. It's nice when the logic/variables for a function are encapsulated entirely inside that function. It also makes it easy to extract functions so you can re-use them elsewhere.

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.

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

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.

There are many reasons. Here's one.

FP is built on theory. The language constructs follow the theory. Part of the theory is algebraic data types which allow for structural recursion. Fancy words that basically come to mean the structure of the code that manipulates data follows the structure of the data it manipulates.

Take a loop typical loop

    var someResult = 0;
    for(i = 0; i < whatever; i++) { someResult := updateResult(i, someResult); }

This uses the natural numbers (integers 0, 1, 2, ...) [Some people define the naturals to start at 1. This isn't important.]

The natural numbers are an algebraic data type and therefore allows for structural recursion. For the natural numbers the structure is, a natural number N is either:

* 0; or

* 1 + M, where M is a natural number

So you write out your structural recursion skeleton

    def loop(n) =
      n match {
        case 0 => 
        case n => loop(n - 1)
      }

This exactly follows the structure of the data, including the recursion.

Then you fill in the missing pieces

    def loop(n) =
      n match {
        case 0 => 0
        case n => updateResult(n, loop(n - 1))
      }

Job done. The theory guides us to the solution. No loop needed.

A lot more here: https://www.creativescala.org/creative-scala/recursion/

The main other reason is equational reasoning aka reasoning using substitution. Described here: https://www.creativescala.org/creative-scala/substitution/

Loops have an implicit ordering, and thus are inherently non parallelizable at face value. map can enable easy parallelization, wether with SIMD or threads or GPU warps or Spark nodes. It's just a construct that specifies less about execution, and thus leaves more room for the compiler/runtime.

This construct is natural with functional programming's abstraction: the function. You encapsulate basic behavior in functions, and then shape the data flow with map(fn)/reduce()/flatmap(). If you really need an index, you can still have them with number ranges, zipWithIndex, etc. If you do use them, you are explicitly reintroducing ordering into your program and lose the parallelism.

This is just a finer level of detail wrt accidental vs essential complexity. IMHO it is always better to specify less about your program, and stick to what you must encode and only that.

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

Writing what could be a loop in functional style instead allows you to say what you want done without saying how to do it. The results is faster to write, easier to read, and leaves the compiler free to find a good way to do it (e.g. maybe in parallel).

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.

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

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> ```

I think it has a lot more to do with readability. Certain conventions are easier to read. This is especially important as we realize that code is easier to read if we don't have to delve into the context.

For example, (I've spent a lot of time in C#,) let's say you have a collection of Foo objects, but you need to convert them to Bar objects. There's two general patterns in C# to do this:

  var bars = new List<Bar>();
  foreach (var foo in foos)
  {
     bars.Add(foo.ConvertToBar());
  }

Versus:

   var bars = foos.Select(foo => foo.ConvertToBar());

Which one is more readable? If you're a newcomer to the language, or you generally haven't worked with "Select" before, the foreach approach might make more sense.

But, as you get used to "Select" and understand what it does, you'll probably come to the conclusion that foos.Select is easier to read, especially if you're looking at code that someone else wrote, where you might not have all of its context in your head.

Some other responses in this thread explain the difference by saying that "loops are saying how you want something done, functional is saying what you want done." This also is helpful when reading code where you don't have all the context in your head. (IE, code someone else wrote, or code you haven't worked with in a long time.)

To provide an example, you could have an array, int[] in C#:

  var sum = 0;
  foreach (var i in values)
  {
      sum = sum + 1;
  }

Or:

  var sum = values.Sum();

Both are valid C#. But, the functional approach is much easier to read, because you don't need to understand as much context when comparing the loop approach to using the Sum() method.

If you're a novice to C#, a novice programmer in general, or you're merely unfamiliar with Linq, the loop approach might seem easier. It's "not wrong..." But, remember, you're saying "how" instead of "what."

A codebase that constantly says "how" instead of "what" ultimately is harder to work with, because it takes longer for everyone to understand each others' code.

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

It's not that they hate loops, it's that once you understand recursion and are able to implement it you never want to go back to loops again. Hearing that from others was the main reason I started learning FP, I wanted to see what the hype was all about and let me tell you it's absolutely true. Go learn recursion and get a handle on it and you'll see why.

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.

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?

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

Let me offer the one thing that functional programmers and imperative programmers can agree on hating: the Common Lisp LOOP macro.

(Which I actually use all the time, if only to save a dependency.)

They don't really.

    for [0 .. n-1] $ \i ->
        ...

does pretty much the same thing in Haskell as

    for i in range(0, n):
        ...

does in Python.

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.

For a loop to do something useful it has to have side-effects[1], and side-effects are what functional programmers want to avoid

[1] At the very least, on variables outside of itself

nobody hates anything. we don't hate while/for/etc loops.

We should just be careful when using them just like any other nested structure (if/else/while-do/switch/select/etc.)

Like if I see ``` for ... { for ... { if ... { } else { } // code here ... } ... } ```

That is objectively bad code and not readable.

Nobody hates anything. Most of us just dont like how people misuse them to write bad code because their managers pressure them.

I'd question the premise. When using an imperative language like C, GLSL or Java, FP'ers do use looping constructs. When in Rome, etc.