5 ms·

> When I started tinkering with JS, I thought of it as slow; but web developers are far more obsessive about speed than any other high-level, dynamically typed

> When I started tinkering with JS, I thought of it as slow; but web developers are far more obsessive about speed than any other high-level, dynamically typed language I’ve seen. Given that, isn't it odd that JS still encourages map/filter array iterations that make multiple passes over a single array? I.e. that it hasn't yet introduced some sort of comprehension or itertools-with-compilation feature that does array processing in a single pass?

goodoldneon 5y ago
Comprehensions are nice and I wish JS had them, but can’t you achieve the same thing with a for loop?
- kwkelly 5y ago
  You can, but transducers would be a more consistent api
bastawhiz 5y ago
JavaScript has generator functions. Comprehensions are really just sugar around this functionality. You could pretty easily write your own set of generator function-powered methods for mapping and filtering.
- brundolf 5y ago
  Which I've started doing, but it is still a real shame that the "default way" is so inefficient, especially given how many devs never even realize it. It contributes a whole lot of accidental-slowness to the ecosystem.
  - pwdisswordfish0 5y ago
    > the "default way" is so inefficient A big reason why I say screw map, filter, reduce, etc. and my "default way" never stopped being ordinary for loops.
    - brundolf 5y ago
      bastawhiz's (correct) point is that it's easy in JS to have the best of both worlds: write your code as multiple, decoupled passes, with the performance of a for loop. The only problem is that in JS you have to go out of your way to do it. But those of us who know about it can, and generally should, do so.
      - andyferris 5y ago
        Though I have found generators in JS often come with an overhead compared to a well-written for loop. (Some languages like rust or Julia will inline all the closures for you and remove all the overhead). Still a great way to avoid intermediate allocations, though.
      - satao 5y ago
        can you point me to a good tutorial showing how to do this? i'm a conflicted web dev regarding loops. I love the simplicity that map/filter have, but I hate that they require looping over the same array more than once, which makes me choose for loops over them... Never thought I could have the best of both worlds
brundolf 5y ago
This may be what you meant, but it's worse than just making multiple passes over a single array: it allocates a whole new array on each pass to hold the results, even for something like a slice()
G4BB3R 5y ago
I prefer to have readable code first, and performance improvement later and only if needed.
- edgyquant 5y ago
  Are you saying you find Array.map(e => f(e)) Easier to read than for(e in Array) { f(e) } I don’t see how they really are any more or less readable, although I’ll admit map gave me a day of rethinking when I switched from 100% python to using react on the frontend.
  - lkschubert8 5y ago
    I think Array.forEach(...) is the more apt analog there as it wouldn't be generating a new array of the return like map would.
    - edgyquant 5y ago
      Maybe, I only went with map since it was in the GP.
  - hnedeotes 5y ago
    Technically you would use Array.forEach(e => f(e)) If you don't care about transformations. Which is basically the same as your for Map is when you want to return a new collection with each original item in it mapped to a "different" thing.
  - brundolf 5y ago
    forEach is an outlier, because most of these methods transform something into something else and can be chained, and that's where the readability increase comes in. I usually prefer for loops over forEach because it emphasizes the fact that forEach doesn't return a value; it's used purely for the sake of side-effects.
  - pwdisswordfish0 5y ago
    Programming punditry makes a lot more sense if, when you see someone talking about the code being more readable, you understand that most of them are lying to themselves about what they really mean. Which is code that is more writable. In other words, something that's easier for them, the lazy person who is punching keys and derping around in a text editor.
WiseWeasel 5y ago
It also offers Array.reduce(), which can filter and map in one go, among other tasks.

goodoldneon 5y ago

Comprehensions are nice and I wish JS had them, but can’t you achieve the same thing with a for loop?

kwkelly 5y ago
You can, but transducers would be a more consistent api

bastawhiz 5y ago

JavaScript has generator functions. Comprehensions are really just sugar around this functionality. You could pretty easily write your own set of generator function-powered methods for mapping and filtering.

brundolf 5y ago
Which I've started doing, but it is still a real shame that the "default way" is so inefficient, especially given how many devs never even realize it. It contributes a whole lot of accidental-slowness to the ecosystem.
- pwdisswordfish0 5y ago
  > the "default way" is so inefficient A big reason why I say screw map, filter, reduce, etc. and my "default way" never stopped being ordinary for loops.
  - brundolf 5y ago
    bastawhiz's (correct) point is that it's easy in JS to have the best of both worlds: write your code as multiple, decoupled passes, with the performance of a for loop. The only problem is that in JS you have to go out of your way to do it. But those of us who know about it can, and generally should, do so.
    - andyferris 5y ago
      Though I have found generators in JS often come with an overhead compared to a well-written for loop. (Some languages like rust or Julia will inline all the closures for you and remove all the overhead). Still a great way to avoid intermediate allocations, though.
    - satao 5y ago
      can you point me to a good tutorial showing how to do this? i'm a conflicted web dev regarding loops. I love the simplicity that map/filter have, but I hate that they require looping over the same array more than once, which makes me choose for loops over them... Never thought I could have the best of both worlds

brundolf 5y ago

This may be what you meant, but it's worse than just making multiple passes over a single array: it allocates a whole new array on each pass to hold the results, even for something like a slice()

G4BB3R 5y ago

I prefer to have readable code first, and performance improvement later and only if needed.

edgyquant 5y ago
Are you saying you find Array.map(e => f(e)) Easier to read than for(e in Array) { f(e) } I don’t see how they really are any more or less readable, although I’ll admit map gave me a day of rethinking when I switched from 100% python to using react on the frontend.
- lkschubert8 5y ago
  I think Array.forEach(...) is the more apt analog there as it wouldn't be generating a new array of the return like map would.
  - edgyquant 5y ago
    Maybe, I only went with map since it was in the GP.
- hnedeotes 5y ago
  Technically you would use Array.forEach(e => f(e)) If you don't care about transformations. Which is basically the same as your for Map is when you want to return a new collection with each original item in it mapped to a "different" thing.
- brundolf 5y ago
  forEach is an outlier, because most of these methods transform something into something else and can be chained, and that's where the readability increase comes in. I usually prefer for loops over forEach because it emphasizes the fact that forEach doesn't return a value; it's used purely for the sake of side-effects.
- pwdisswordfish0 5y ago
  Programming punditry makes a lot more sense if, when you see someone talking about the code being more readable, you understand that most of them are lying to themselves about what they really mean. Which is code that is more writable. In other words, something that's easier for them, the lazy person who is punching keys and derping around in a text editor.

WiseWeasel 5y ago

It also offers Array.reduce(), which can filter and map in one go, among other tasks.