Stop Telling People For Loops Are Bad

For breaking a loop in javascript you can use .some() functional method, which return false as default, but you can return true (with a break functionality), when your condition passed. For example:

const arrayList = [false, true, false, false];

arrayList.some(arrayItem => {
if (arrayItem === true ) {
// your business logic...
return true;
}
});

for only makes sense in languages where you have to manage memory yourself and/or you don't have easy access to true higher order functions.

Once you start passing functions as arguments, fold and its children make your life way more easy to deal with.

Take this contrived Haskell example:

isLetterA :: Char → Bool
isLetterA c 
  | c == 'A' = True
  | c == 'a' = True
  | otherwise = False

stripChars ∷ (Char → Bool) → String → String
stripChars cfn = filter (not . cFn)

stripChars C.isSpace "I made a string!" -- Should return "Imadeastring!"
stripChars isLetterA "I made a string!" -- Should return "I mde  string!"

Ok, that's unreadable... let's convert it into its rough Javascript equivalent:

function isSpace(c) {
  return c == ' '; 
}

function isLetterA(c) {
  return c == 'a' || c == 'A'
}

function negate(boolFn) {
  return (v) => !(boolFn(v));
}

function stripChars(charFilterFn) {
  return (s) => s.filter(negate(charFilterFn));
}

stripChars(isLetterA)("I made a string!"); // should return "I mde  string!"
stripChars(isSpace)("I made a string!"); // should return "Imadestring!"

I know it looks like a lot, but it's a REALLY powerful concept that lets you make even MORE reusable things while not having to increase the complexity of the underlying building blocks. For small examples like this, it seems like a lot of overhead, but combined with a strong type system (and tail call optimization) you can more easily make trivially correct programs.

I wish I had the words to convey this better, but it's part of what makes functional and declarative styles so powerful and so difficult to get into after really learning the imperative style. Also, the fact that languages like c, Javascript and Python have dealt with recursion and corecursion so badly in the past hasn't helped us either. fold really relies on recursion as an underlying concept.

Interesting as I responded to a similar inquiry.

forum.dlang.org/post/suinxiufqltip...

foreach(i; iota(10)
    .filter!(x => x%2)
    .until!(x => x>5)
    .map!"a * a"
    .filter!(x => x%4)) {
    i.writeln;
    break;
   }

But it was with a language where libraries are written with generic iteration. Yes arrays are used heavily but only stack allocation for this example, with early exits and multiple filtering.

But your context is Javascript, and context is important because as you point out it costs where functional languages can play tricks.

I just want to note that JS could be a better language if they'd just learn from others, and the community could get behind doing things better.

Thanks for sharing your view.

I have to say I disagree on your basic premise, though.

The whole purpose of methods such as map, filter and reduce is preventing the mutation of what gets passed into them.

This is a misconception, in my opinion. Although immutability does indeed contribute highly to readability and reduces bugs, the main benefit of this kind of list processing is in how it communicates intent.

With for loops, every example is different. Each loop must be read, parsed, and mentally executed in order for the reviewer or maintainer to understand what it's for (pun!) The only exceptions to this rule are for loops that closely mimic the behavior of map, by deferring their bodies to some function, but even in those cases your stuck with the semantically useless i variable in the body.

Consider

let betterThings = []
for (let i = 0, i < things.length, i++) {
  const thing = things[i]
  const newThing = betterThing(thing)
  betterThings.push(newThing)
}

The only part of line 2 with any semantic meaning is things

By contrast; map, filter, and reduce always mean the same things. They are a shared interface representing classes of procedures. forEach communicates the intent to do side effects, map to mutate, reduce to produce a single value from multiple values.

const betterThings = things.map(betterThing)

To my eyes, this is vastly superior at communicating intent. The amount of verbiage in the first example... Who has time for that?

And remember that the first snippet is the best case of for loop. In most cases, you'll have to read several lines of imperative statements in the body in order to make heads or tails of what's going on.

That being said, just typing .map( won't magically solve all of your readability problems. Naming your functions semantically is key, avoiding lambdas in almost all cases helps.

Ultimately, one needs to adopt the mindset and goal of communicating their intent from the most to least abstract steps, starting at their program's entry point (usually at the bottom of the file) and working their way down.

Now that doesn't mean we should dogmatically forbid all loops. You're right when you say that loops can improve performance in cases. But let's not sacrifice semantics, maintenance, and readability for performance gains which may not be necessary or helpful.

Write semantic, well-abstracted code first. Later, identify and ameliorate performance bottlenecks on a priority basis.

Thanks again for kicking off the discussion!

Thanks for the post, I have had similar thoughts about this topic but it seemed like I was in the minority in feeling that way about these functions. I think it is seen and taught as the "modern ES6 way", but as you mentioned these are functions added for convenience/functional programming and not the new default for looping. I think the appeal is that it looks cleaner and the code can be shorter, but I'm a fan of easy to understand code as opposed to one-liners.

In addition to your examples, I have also seen some roundabout ways of using these functions when there is a simpler and more performant way.

• A result set pulled from the database or API then immediately has a filter run on it. I think this is better suited for the database to do the filtering, I cannot think of a good use case for doing this unless it was not possible in SQL or in the API.
• Converting a non-array iterable into an array for the sole purpose of using the map function on it. It seems like a wasted step when a regular loop will work on it.
• Chaining/running all three (map, filter, and reduce) on the same array. I cannot remember the exact use case, so it may have been valid, but I'm confident there was a simpler and faster way to achieve the same result.