Additionally the for construct implies that you want something done in a certain order, map implies all operations are independent and the order can be decided by the runtime itself. A program written in a language supporting map (which requires first class functions) can be trivially parallelised, whereas every for loop must be carefully analysed first.

Then replace the for loop with a parallel construct that's imperative. In terms of the language itself, map, reduce and filter are just sugar... different ways to loop through collections. Using one does not mean you are using FP, using immutability in java means that you are. That is the difference.

Actually, for loops in languages like Ruby and OCaml are just syntactic sugar for map.

Also, why would you prefer an imperative construct over different kinds of folds?

I don't. My point is, it's all sugar, so in a sense it's the same thing when you're doing imperative programming. Whether you use a map or a for loop in your imperative code the structure of your program remains the same, the only difference is sugar... This is my point.

Why are maps and folds so prevalent in functional programming? Because immutability and imperativeness render the concept of a for loop to be non-existent.

Try to use a for loop with all const variables and no IO... your for loop will not be able to do any meaningful change to the state of your program.

Obviously the for loop either transforms a list, or builds up a new list via an accumulator. That accumulator or the original list is your return value that you can imperatively pipe into other for loops.

You realize that reduce, filter and map are all higher order functions that can be implemented with for loops?

Yes because for loops are syntax sugar around gotos. It all boils down to the same thing. However maps can be determined to be turing incomplete if the mapped function has no function calls and no loops and if the input list is not infinite. This means that it's suitable for a wide range of dsls that would like to know if programs are susceptible to the halting problem (e.g. bpf -which doesnt have maps but I think it could...)

You just said a for loop returns no results. I responded saying that it can via an accumulator or mutating the original list...

Are you indicating in your latest response that I am correct and your original statement is incorrect? You seem to be going in on a tangent... Where is this going?

Returning a result and modifying a data structure you've decided to use as an accumulator are two different things. Modifying the original structure is even more different.

Most of the traditionally non-functional languages don't support loops as expressions.

Yes, I get what your saying, but I can implement the map filter and reduce abstractions with a for loop using this accumulator pattern or pass in the parameter by value (aka copy) then modify the original structure. If I can implement MAP using a FOR loop then they are relatively the same thing as I can just replace a MAP with it's FOR loop definition and get the same result.

Here's my main point. There is no meaningful change to your imperative program when you replace for loops with maps. The core structure of your code is exactly the same. What you have introduced is a convenience aka sugar.

If you were to truly do functional programming the architecture of your entire program will be drastically different from imperative code... To counter the posters original statement: There is a gigantic difference between just using map and reduce in your imperative javascript code vs. actually writing a functional program... It is not a trivial difference.

I feel many people who understand javascript fp libraries like underscore think they know functional programming when all their really doing is sprinkling map and reduce all over their imperative code. You guys don't get it yet, and you'll never get it if you keep coding in javascript. The difference is night and day, it's like SQL vs python.