7 ms·

hey man - 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

hey man - 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

bryanrasmussen 5y ago
ok, maybe I'm too aggressive lately, but the only reason to do a break is to stop iterating over the array. You can easily achieve the output of using break using filter, but you cannot achieve the behavior because filter goes over every item in your array. 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.
- setr 5y ago
  If the language implements them as lazy iteration, then I think take_until would be effectively equivalent to break, with early exiting behavior. List.where(…).map(…).take_until(…)
  - bryanrasmussen 5y ago
    maybe, but that seems a weird way to say you can do it.
  - dragonwriter 5y ago
    > If the language implements them as lazy iteration JS doesn't, though. > then I think take_until would be effectively equivalent to break JS also doesn't have take_until.
    - bryanrasmussen 5y ago
      >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.
- xigoi 5y ago
  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)
  - bryanrasmussen 5y ago
    I don't see where you used map? You made a recursive function? the argument was clearly stated - person says all most programmers need is map and reduce on arrays. I agree that by recursing you also have found another way not to use break but you have evidently had to NOT use map and reduce to do it? 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?

bryanrasmussen 5y ago

ok, maybe I'm too aggressive lately, but the only reason to do a break is to stop iterating over the array. You can easily achieve the output of using break using filter, but you cannot achieve the behavior because filter goes over every item in your array. 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.

setr 5y ago
If the language implements them as lazy iteration, then I think take_until would be effectively equivalent to break, with early exiting behavior. List.where(…).map(…).take_until(…)
- bryanrasmussen 5y ago
  maybe, but that seems a weird way to say you can do it.
- dragonwriter 5y ago
  > If the language implements them as lazy iteration JS doesn't, though. > then I think take_until would be effectively equivalent to break JS also doesn't have take_until.
  - bryanrasmussen 5y ago
    >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.
xigoi 5y ago
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)
- bryanrasmussen 5y ago
  I don't see where you used map? You made a recursive function? the argument was clearly stated - person says all most programmers need is map and reduce on arrays. I agree that by recursing you also have found another way not to use break but you have evidently had to NOT use map and reduce to do it? 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?