forEach emphasizes you are operating on each element of the loop in a semi-independent fashion and you explicitly don't have access to any kind of intermediary index/iterator variable.

When you "drop down" to a classic for loop you're telling the reader that you need access to the index/iterator for some reason (and there are plenty of valid reasons for that).

If you only use classic for loops then the reader has to be constantly vigilant you're not doing any index/iterator shenanigans. It's just higher "cognitive load"

I disagree with this point, specifically for JavaScript the for...of syntax is more pleasant to read and also does not infer that any index access is gonna be done. And as a plus, it is easier to be used with async/await.

  await Promise.all(collection.map(thing => some_async_function(thing)));

  for thing of collection {
    await some_async_function(thing);
  }

Yeah, the “map and friends pass extra parameters that are usually ignored” plus the “lots of JS functions optionally take extra parameters that are usually unused” makes it so easy to think of a function as a one-arg function when its really one plus multiple optionals, use it bare in a map, and get stung by it.

Is it bad to use map?

So if you're using map sensibly, no there's nothing wrong. But I don't like the dogma I read a lot which is "use map always" because it leads to inexperience developers using it in the wrong circumstances.

> Is it bad to use map?

No.

flatMap takes care of a lot of that

For posterity (and forgive me if this JavaScript syntax is inaccurate; I don't write it so much these days)…

    xs.map(a => shouldBeSkipped ? a : f(a))

Btw, I'm assuming that the original map questioner wasn't solely using flatMap for side-effectful iteration, which reading again, I'm a bit suspicious about.

1: https://gcanti.github.io/fp-ts/modules/Array.ts.html#filterm...

If you want something that behaves like:

  array.map(x => {
    if (x > 2) { break; } // can't really use break here!
    else { return x; }
  });

  [...array].map((x,i,a) => {
    if (x > 2) { a.splice(i); }
    else { return x; }
  });

so I guess I was wrong, you can get the same functionality of break in map, albeit in a way that, right at this moment, makes me uneasy.

Let me know what it is you're trying to achieve — at a high level, not in terms of specific implementation details — and I can show you how this might be expressed without using anything as low-level as a `for` loop.

so to clarify - I am not asking for your help in solving my programming problems. You made a response to another poster asserting that >all most programmers need is either `map` or `reduce`

that poster said >I find it really difficult to believe that there are developers out there that never need to be able to break or continue in a loop.

you said >I’m not sure where you got “never” from in my comment.

I, in my normal long-winded way gave you the benefit of the doubt that you meant something else but advised the previous poster had assumed you meant more than 50% of programmers will not ever need other array methods than map or reduce and hence was confused because you cannot break or continue with those (with map and reduce together you can implement something that has the same end effect as continue but it is not 100% the same of course)

but for some reason you just wanted to keep saying you were right and others were wrong even though the clear meaning of everyone's text was - you can't break in a map.

And you said:

>Regardless of how you choose to interpret my comment, it is the case that both `break` and `continue` are literally never necessary, as those two constructs can be implemented in terms of `map` and `reduce`.

frankly exasperated I said

>ok, how do you implement a break of the iteration in map in JavaScript? I believe it cannot be done, you believe it can? Teach me.

now admittedly here you may think I am confused and need help, but really I am saying you are wrong in a nice way when you say break can be implemented in map. But then you say:

>There is no sensible way to `break` the iteration while mapping. That's not what `map` is for.

right, what everyone's been telling you from the beginning.

>Let me know what it is you're trying to achieve — at a high level, not in terms of specific implementation details — and I can show you how this might be expressed

Thank you for your kindness but it should be obvious from the whole conversation nobody is asking you for programming help here, they are just saying your initial statement of most programmers only need map and reduce was overly bold.

As to why someone might want to break a loop, generally you do that when you have a long array - say 10000 items (don't bother telling me that 10000 is not a long array, I know, but a long array is often used as meaning an array requiring a lot of processing and that is partially determined by what you need to do with that array, if that is not good enough for you arbitrarily add 0s to the array length until you feel you have a long array) and have a number of conditions that can cause you to only have to process a number of them which probably in that case you would use find (because often in such a case you are processing an array to find one item in it) or if for some reason you needed to drop down to a lower level I would prefer to use while instead of a for loop because semantically I think while indicates to anyone reading the code without going into the loop - hey Bryan doesn't expect to have to look at every element of this array!

BUT ALL THAT DOESN'T MATTER - because the subject matter of this long discussion was you saying most programmers only need map and reduce and someone asked why do you think most programmers will NEVER need to break. And you wanted to know why they assumed that you thought most programmers would NEVER need to break because evidently you felt you never said anything remotely like that.

i don't think you really listened to the other guy.

i think he's saying that there's no need for break/continue with FP

because you simply approach the problem from a different angle

it's a different paradigm

that's probably why he asked for an example (not to belittle you)

i might do a filter before a map to recreate a lot of the functionality of a continue or break

and when I wrote/write OOP I might avoid break/continue because these things can be leaky

Probably the most common reason you want to break is that you found what you were looking for so find is what you would use.

so to make an example that would not be reasonable for find:

you have a long array of objects, you need to display 5 of the 'interesting' objects out of this array. What constitutes 'interesting' is determined by some relatively complicated logic on each item in the array. Since you do not know how many items in this array are interesting you want to process all items until you have 5 items. When you have 5 items you want to stop processing items therefore you break, if your first 5 items have the property of being 'interesting' you just saved a lot of work in your application and things feel zippy so you want to do that (because your application maybe needs the help at this point)

It is obviously, as all examples when one does not need something at the very moment, somewhat artificial - but I would say it is not unthinkable.

However, as I made clear earlier, I am not arguing for the necessity of break - if I wanted to do what I just described I would probably use while unless the syntax became unwieldy - I dislike break.

The only reason I got into this is because someone said they didn't believe most programmers wouldn't ever need break (which can be used to stop iteration of an array) and the guy who said all most programmers needed was map and reduce (both of which iterate over every item of an array) then said they never said most programmers wouldn't need break.

Because JS’s map and filter provide the index and array as arguments, you can, in fact, achieve the behavior of break. If you need the original array after the iteration, you need to apply the map or filter to a copy, though, because the way to achieve the behavior of break involves modifying the array by deleting all the items after the current one, which stops the iteration.

I guess it's a failure of imagination on my part not to have realized that I could modify the array length in that way, or really the failure of imagination was not seeing any good reason for sending the original array in as a parameter to map - when I saw that in documentation I thought what a weird idea!

List.where(…).map(…).take_until(…)

JS doesn't, though.

> then I think take_until would be effectively equivalent to break

JS also doesn't have take_until.

I just assumed it was a new method coming out soon! Although when I was thinking of how I would make a method I just thought an until method that iterated all elements of an array outputting them until it got the return from the callback that was passed as the iteration stopper - default value null.

  const findInterestingItems = (arr, isInteresting, num, i=0) =>
    num == 0 || i >= arr.length
    ? []
    : isInteresting(arr[i])
      ? [arr[i], ...findInterestingItems(arr, isInteresting, num-1, i+1)]
      : findInterestingItems(arr, isInteresting, num, i+1)

on edit: also how will that recursion perform on the large array we've supposed as being used if it turns out that we don't get our interesting items in early parts of array?

FP is a higher level paradigm so you might have to trade off with performance too

Then it can hardly he said be to unequivocally be better, can it.

Functional programming is a higher level abstraction. If the underlying implementation is not well implemented/optimized then you could have bad performance while the opposite is also true.

Yes, it is like saying that. At least, assuming by "cannot be" you mean "is not".

>not doing your own memory management is bad

No, it's not like saying that. Note how differently those claims are phrased.

Of course if it were assumed they never need anything but the higher level methods: map, reduce, some, every etc. - then they would probably use some or every if they wanted to break.

I suppose filter could maybe be hacked to do it in some cases dependent on implementation, if the implementation determined that it was impossible to ever return true for any of the items remaining in an array that implementation might effectively break the array processing however every way I can think of doing that would be artificial, horrible, and probably full of side effects.

No it doesn’t.

If I only need to do X

And X cannot do Y

Then I do not need to do Y

-----------------------------

If I need to do Y

And X cannot do Y

Then I need to do something other than X

-------------------------

Give your answer of no it doesn't please be so kind as to outline the logical reasoning that you are envisioning?

on edit: added line between logical statements.

on edit: although I almost never break in a loop, I use some other construct instead.

on second edit: maybe I should say iteration instead of loop but will let it stand.

You actually don't need `map`, you can easily implement that using `reduce` too ;)

https://twitter.com/jaffathecake/status/1213077702300852224

There is utility in communicating whether you're working with a catamorphism vs a homomorphism. Code is written for humans, after all.

Also I think `forEach` is great for cases such as `arr.forEach(f)` where `arr: Array<T>, f: T => void`.

ForEach does get you both.

I don't remember using for loop for at least 3 years previously as a frontend engineer :)

It is longer than:

array.forEach((value, index) => {})

… but forEach has too many limitations (no exits, no await, …)

I'll give you await (gotta use awkward reduce there) but if you want exit, you're better off with something like `find`

Another advantage is that array functions better convey what are you trying to do with this particular operation.

I strongly disagree.

  > ['1', '2', '3'].map(parseInt)
  [1, NaN, NaN]

  > ['3', '2', '1'].map(parseInt)
  [3, NaN, 1]

// Consider: ["1", "2", "3"].map(parseInt); // While one could expect [1, 2, 3] // The actual result is [1, NaN, NaN]

// parseInt is often used with one argument, but takes two. The second being the radix // To the callback function, Array.prototype.map passes 3 arguments: // the element, the index, the array // The third argument is ignored by parseInt, but not the second one, // hence the possible confusion. See the blog post for more details

function returnInt(element){ return parseInt(element,10); }

["1", "2", "3"].map(returnInt); // Actual result is an array of numbers (as expected)

The normal solution is to write an inline function; “shortcutting” it by just passing a named function directly can be nice when it’s appropriate, but it often isn’t what you want to do

Yes, it is.

Its about .map(), and the broader design of the API around it. Yes, map passes extra args and parseInt takes optional args, and it wouldn’t be a problem if both of those weren’t true. It would be better if .map() was one-arg and had friends .map_with_index(), .map_with_collection(), map_with_index_and_collection().

(It would be better if .map() wasn’t an Array-specific method but part of a general collection protocol that returned [and was applicable to] generators instead of returning Arrays, and then you also had companion methods to like .enumerate(), but that’s…well, farther afield.)

> The normal solution is to write an inline function

Yes, that’s the solution, but that doesn’t say that the design of .map() isn’t a critical component of there being something to solve in the first place.

Also, the silently ignored argument count mismatch errors heavily contribute to the problem. You may have used other functions with map() and never knew it's always passing an extra argument in, because JS silently ignores this error.

As far as ignoring errors silently, sure, but I’m not even sure what the error would be in this case. Index is a number and radix is a number; even typescript won’t complain about this because the types line up.

https://github.com/raganwald/javascript-allonge/blob/db7c435...

Only because .map() is an Array method, not a method of a generic iteration protocol applicable to other iterables (including generators.)

In Python, while map is a built-in function instead of a method, and you’ll probably want a comprehension instead, if you want the index for a map (or in a comprehension), you just wrap call enumerate() and go from an iterable of items to an iterable of pairs of (item, index), so:

  map(f, enumerate(collection))

   collection.each_with_index.map {|item, index| … }

The error I was talking about was the argument count mismatch erorr, that would have taught you on all the other times you used map() without knowing about the extra index argument.

Yes, but only because of other non-ergonomic design decisions of the API its part of (particuarly, that it is an eager API attached to the Array class returning Arrays; if it were a lazy API of generalized iterable protocol that returned and could be used on generators, then you could just also have an “enumerate” and “with_collection” companion methods, but as it is, even if you made standalone functions for those purposes, for the output to be used with .map() you need them to return Arrays, which means you are accumulating bulky intermediate results.)