Map, fold, reduce and friends are statements of intent, and reading a line of transformations composed on multiple maps and such is generally much clearer than reading a series of loops in which you have to figure out intent by looking and what's going on inside each loop.

Also, error density is relatively constant per line of code according to most studies (this is a very general statement, but we can assume that most code just isn't trying to be clever). I've forgotten to add(), append() and drop items inside a loop far more than I've made mistakes inside more functional methods.

I would argue that for loops are imperative, map/fold/etc are more declarative. That leads to various benefits such as less code, fewer bugs, fewer off-by-one errors.

And, man, tail recursion in a language with function head pattern matching (ML family, Erlang) is so much easier to read than any complicated for loop.

(Update: realized afterwards that "foreach" isn't quite the same as "for", but the larger point still stands, mostly.)

No it doesn't, because map, flatMap, and reduce can be lazy, distributed across local processors, or even the network.

They describe the intent of what to do with the data, not how it is done.

Just like using SQL versus an old xBase database to access data records.

And a goto statement is even more general, covering all kinds of looping constructs, exceptions and even the eliminating the need for functions! Why not just use those?

For loops are yet another of these useless abstractions introduced by the academia, this time straight from the design-by-committee language ALGOL 60.

We all know real programmers used gotos.

Technically, reduce covers map, flatmap, filter, etc. It's every bit as flexible as a for-each loop (the only difference is it implies no side effects, but does not guarantee them if the language doesn't).

The very reason those other functional constructs were split out was not due to need, but due to -clarity-. And that same clarity applies to why to use one of those constructs instead of a for-each loop.

The problem with for-each in a lot of languages is that it's a statement, not an expression, so it only works with mutable data.

I'm definitely in camp map/filter/fold, but if you instantiate a list/accumulator, fill/operate on it inside the loop, then consume it, you're essentially writing pure code. The fact that you're doing it on top of mutable foundations doesn't matter (at that scale).

The trouble is that safe mutation and dangerous mutation look very similar. It's possible to write a function that performs safe, locally encapsulated mutation, sure - but it's much harder for a reader to confirm those properties in code review or when debugging compared to just seeing that the code doesn't do any mutation at all.

As long as you get your mutable code right. If there are any unintentional holes in your instantiate/operate/consume box...

There just isn't that much to get wrong in pure for-each loops:

    def filter_broken(widgets):
        broken_widgets = []
        for widget in widgets:
            if widget.is_broken():
                broken_widgets.append(widget)
        return broken_widgets

The actual errors with loops and mutable objects come from complex nested loops, continues/breaks (multi-level ones especially!), extra boolean conditions, and sharing mutable objects between parts of the code base.

I think that overstating the supposed risks of for-loops doesn't help anything. The problem is not that you're going to mess up a simple for loop. It's the ways that your code doesn't compose well that are more problematic. Oh, and the verbosity sucks too.

Hm. Wouldn't your code reverse the order of the list?

Maybe that's right, maybe that's wrong, but it's indeterminate from the code whether it's desired, whereas a filter function and a reverse function would make it explicit.

Append is a function that adds it to the end of the list. (I think my code is working Python, but I haven't actually run it).

Btw: I'd venture to guess that you're not a Python person, and that's why it's not obvious that it constructs the method in the same order. In imperative languages (where Python isn't the perfect example b/c it has filter and list comprehensions), you get so used to these loops that you don't have to worry about questions like that.

If you wanted a reversed list, you'd either name your function appropriately, or call reverse after you run the filter method. It's a little painful to do the first bit.

Yeah, sorry, got my mental model mixed up. I worry about reversing lists a lot since I deal with TCO so much.

> So why have three or more specialized constructs when one will do?

Because having three specialized functions for three specialized operations makes it easier to see what a given piece of code is doing. One function per function.

When I was first introduced to scala my very favorite thing was the existence of map. I'd been using java for a while and missed it dearly

Not allowed to use Java 8?

Didn't exist at the time. While I still prefer scala to java 8, had the latter been available at the time I likely never would have dabbled in scala in the first place, if that makes sense

Sure it makes sense.

I dabble in what sorts of programming languages, but when comes to work, it is mostly C#, Java, JavaScript and some occasional C++, because that is what customers pay for.

Hence why I see a big value in mainstream languages slowly evolving into multi-paradigm ones, as many of us don't have the luxury to move beyond the first class languages of each platform.

side effects ? testing ? decoupling ? (thus reuse)

If your brain is organized enough to write clean for loops then ... maybe. But it's a bit opportunity for problems. At least to me; but then I may not be smart enough.

I think for tasks such as JSON parsing, map and flatmap like functions are really helpful. You write less code and the code is way easier to understand (for those who are familiar with map functions).

That being said, map and flatmap force immutability in some way. So you pay a price for this, either in speed or in memory, even with tail recursion.