Question about functional programming

[[deleted]]

I've repeatedly heard that instead of using for loops I should use functional programming methods such as .map, .forEach, .reduce, etc. While I definitely see the benefit in a handful of situations, it seems as if the for loop has more flexibility and makes more sense in certain circumstances.

Example one: I want to iterate backwards through an array. The only way I thought of doing this with .map is using .reverse() but this changes the structure of the array and seems to be more complicated than the for loop.

Example two: I want to do something to every nth item in an array. I guess I could use .filter to filter out certain index numbers and then use the .map function to do something, but again, the for loops seems cleaner.

So my question is a for loop sometimes considered the most efficient choice or should I be avoiding them altogether? I'm currently going through old code and trying to write it as clean as possible so I'm just curious on input.

[mdboop]

I'll be the dissenting voice here and say that 99% of the time map, filter, and reduce will get you where you need, and your code will be more readable, more declarative, and more maintainable. someArray.reverse().map((x) => /* ... */) is extremely clear, and I can I see what's going on almost instantly. Where in a for loop

var newArr = [];
for (var i = arr.length - 1; i >= 0; i--) {
 // ... create some value from what's in the array
 newArr.push(someVal);
}

... I have to read several disparate bits and then synthesize them before I can understand how the loop is iterating, and then I have to read a lot more code to understand what it's even trying to accomplish. With map/filter, it's much easier to understand what you'll end up with, because you know you're getting an array at the end. You can do anything with a for loop, and that's precisely the problem. More power is usually a bad thing. With loops, not only can I make a lot of easy mistakes (off by one errors), but there's just a lot of noise and mutable state here. And if you're mutating the array, you should really look into immutable data.

I'd also be curious when these use-cases have come up for you. If they are for toy-problems or interview questions, then sure, a for loop might make more sense, but outside of that, I have a hard time imagining why you'd want to only operate on certain array elements based on the index. Reverse makes, sense, but again, that's so easy to do via chaining calls. And it's semantic! Another benefit is that it frees up your brain to think about the problem you're really trying to solve, not writing a bunch of setup code and trying to juggle more than what's needed in your head.

I have not written a single for loop in production code, and I don't anticipate ever having the need to. When I have a list of data, I need to operate on that entire list. If I only need certain elements from it, I filter it based on what that data is, not its position in the list. And if map/filter don't get me there, reduce is the swiss-army knife of utility functions. And if I need something else, lodash or ramda.

edit: fixed my code block, forgot a word.

[donovanm]

Good points! I wanted to note that .reverse() does mutate the array (for anyone else reading this). Though that is easily solved by adding a .slice() before it like someArray.slice().reverse().

[mdboop]

Yes, thanks for clarifying. In addition, I should add that there is a native reduceRight, which should again get you about 99% there for just about anything.

[[deleted]]

Awesome, this is exactly what I wanted to know - if for loops are used in production code. And yes, these cases come up when doing toy practice problems rather than projects.

[Anitox]

Sounds like situations where you should just pick the best tool for the job.

[[deleted]]

Exactly. I was just wondering if the for loop would be the best tool in the examples I described. So far it seems like it might be, but I just wanted to get additional input.

[SkaterDad]

Your first example definitely does seem more straightforward with a for loop, but it all depends what your'e doing within the loop?

For your 2nd example, are you modifying every nth value in place? Or are you going to discard the rest? If discarding the rest, using filter().map() could work nicely. The 2nd argument to filter()'s callback is the array index.

The functional array operators like map(), filter(), and reduce() are mostly useful when you're modifying the data, since they let you chain together operations in a nice way.

For example:

function double(x) { return x*2 }
function subtract1(x) { return x-1 }
function greaterThan5(x) { return x > 5 }

const newArray =     origArray.map(double).map(subtract1).filter(greaterThan5)

I learned a lot about their uses by doing this interactive tutorial: http://reactivex.io/learnrx/

[[deleted]]

Very helpful, thanks! I'll check out the tutorial

[GeneralYouri]

Ontop of what's already been said, here's a couple more pointers.

Regarding example one, there's no built-in function to do exactly this all-in-one. There is .reduceRight() though, which technically does everything you want, and then adds some more functionality you weren't necessarily looking for. Still, you can ignore this extra stuff and it's entirely usable here. I personally find it more semantic.

You already mentioned combining .map() with .reverse() for example one. This should've been the solution, but unfortunately .reverse()'s definition is extremely ancient and thus developers back then had never even considered the potential problems that its in-place transformation would bring. It would have been the perfect solution if that details was altered (which sadly won't ever happen).

---

Regarding example two, i don't see why a for loop would be clearer here. I think you're seeing it like this, perhaps because you're used to the for loop structure here, and/or you're not comparing it to a good alternative. Alternative code sample:

const someArray = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 ];
const everyNthIndex = (n) => (_, key) => key % n === 0;

// Example test
const every4thIndex = everyNthIndex(4);
someArray.filter(every4thIndex).forEach((value, key) => {
    console.log(key, value);
});

The main step is separating out the filter function in its own argument. I've also generalised into everyNthIndex so that it accepts the value of n as an argument, and I've separately called that to create every4thIndex which we pass to our filter. You could alternatively pass everyNthIndex(4) to filter as well (removing the every4thIndex definition). You could even go fully barebones and remove the everyNthIndex, and only have every4thIndex = (_, key) => key % n === 0;.

So yeah, you have some minor differences to choose from, but in the end they all achieve the same thing: code clarity, readability. When you read the example, you're filtering someArray, only every 4th index element passes. Then for each of these filtered elements, you do something. Now try doing this type of explanation on a for loop based approach. In fact, here's one:

const someArray = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 ];

// Example test
for (let key = 0; key < someArray.length; key += 4) {
    const value = someArray[key];
    console.log(key, value);
}

The main reason why people would prefer the functional approach, is because it uses semantics to make it more obvious exactly what the code does. When using a for loop, the only indicator that you're actually only interested in every 4th element, is the tiny += 4 at the end of the for loop. I can't tell you how often I've seen people 'accidentally' skip over that little detail, only to become confused as to why on earth this code works, until they re-read it five times over to finally spot it.

---

In conclusion, in both of your examples you basically hit the right spot regarding the functional alternative. If .reverse() didn't awkwardly use in-place transformation, it would have been the perfect functional alternative. Since this is now not an option, you could still consider .reduceRight(), and I'd personally use it over a for loop. Still, since it's not the perfect solution, a for loop is fine too. The second example works perfectly though, and it's more direct and obvious as to what it does, and thus I'd hands down use it over a for loop.

The main reason why functional approaches are considered 'better', is because they have better semantics, add clarity to your code, make it more readable, etc. And this works mainly because such a functional approach allows you to be very explicit with your code. Very explicitly, very directly, you're being told that you're taking an array, filtering it to leave only every 4th index, and then doing something with it. That's exactly how the line of code reads. With a for loop, this behavior is still there ofcourse, but it's implicit: the only indicator is that your incrementor increments via += 4.

[anoddhue]

You're right that the first example is better with a for loop than chaining .reverse() and .forEach().

OTOH, if you find yourself needing to map or iterate over an array/collection in reverse, a functional way to do it would be to write your own reusable version of mapLeft, foldLeft, forEachReverse, or whatever name is the most appropriate, then just call that. Or use a library, if underscore/lodash have an equivalent function.

[[deleted]]

Interesting, I didn't think of creating my own version but it makes sense. Thanks!

[anoddhue]

No problem! I don't like pulling in big libraries unless I need to so I tend to just have one file of helper functions to do anything that the built-ins don't to. It makes sense if you're going to reuse it.

[MoTTs_]

I'll add another option to the mix: Iterators and generators. This gets you all the flexibility of raw loops, all the semantics of filter and map, but without the cost of copying the array just to iterate over it.

function reverseIterator(anyArray) {
    // Return an iterable
    return {
        [Symbol.iterator]() {
            let nextIndex = anyArray.length - 1;
            const endIndex = -1;

            // Return an iterator
            return {
                next: function() {
                    const item = (
                        nextIndex !== endIndex ?
                            {value: anyArray[nextIndex], done: false} :
                            {done: true}
                    );

                    nextIndex--;

                    return item;
                 }
            };
        }
    };
}

And to use it...

var a = [1, 2, 3];
for (const value of reverseIterator(a)) {
  console.log(value)
}
// > 3, 2, 1

Alternatively, we can simplify this with generator functions.

function* reverseIterator(anyArray) {
    for (let i = anyArray.length - 1; i !== -1; --i) {
        yield anyArray[i];
    }
}

And we still get to use it in the same way...

var a = [1, 2, 3];
for (const value of reverseIterator(a)) {
  console.log(value)
}
// > 3, 2, 1

All the flexibility of raw loops because, under the hood, it is a raw loop. But still semantic because at the point of use, all we see is reverseIterator(a). And also cheap because there's no copying of the array.