Hacker News Reader

Comment by vorticalbox | Hacker News Reader

> us JS programmers play fast & loose with "a little filter" here, "a little map" there, and end up with death by a thousand allocations.

That's because speed isn't always top priority. Readability is very high on the list.

I would rather have a slightly slower .map or .filter in a chain than a harder to read nested for or while loop.

View on HN

This just shows again that readability is entirely subjective, IMHO combinations of .map, .filter, .reduce, etc are often less readable than doing the same thing in a nested loop.

This is true I code very functional style in javascript but I can see how that might be harder to read for some.

> combinations of .map, .filter, .reduce, etc are often less readable than doing the same thing in a nested loop.

I often find map/reduce/filter easier to read when using named functions (or lazy data structures ) for intermediary results - depending on the language/runtime that might imply more allocations - or not.

Eg pseudocode:

Integers.filter(//non-obvious prime sieve).sum()

Primes = Integer.filter(//non-obvious prime sieve)

Primes.sum()

Or lifting the anonymous filter to primes()-filter:

Integers.primes().sum()

That's an interesting point. Agree that readability is somewhat subjective, but many programmers find .map, .filter, .reduce, etc... as more convenient and provides clarity as to their intentions. Many languages (like Vlang, Java, Python, etc...), arguably also have them to more closely align themselves with the functional programming paradigm.

For simple combinations I agree (maybe 2-long chains with very simple conditions and transforms - but for such things loops are also trivial to read).

But I have seen "functional contraptions of horror" where those functions are both chained and nested which were completely undecipherable by mere humans.

And at least from my personal impression, people who are a fan of this type of functional style are also more likely to create such horrors (which they themselves of course find totally readable and superior to "unreadable" loops) - I suspect that there's often a bit of cargo-culting going on.

A nested for or while loop isn't always less readable FWIW. If you need more than 3-4 filters and/or maps the balance starts shifting back the other way.

yeah, cause fixing the missing index on your DB that adds 3 seconds to an API call is better than optimising loops to save 2ms.

In the front-end we were making about 20 API calls to fetch data we probably don't need yet and the developer is like: the problem has to exist in the way we call them, time to optimise the loops!

Well-factored code often reveals more important optimizations one can make. Like figuring out the nested loop isn't really necessary.

The fact of un-readability isn’t necessarily implied by the statement being replied to. `map` and `filter` are names for common operations on lists, not less performant alternatives other things. If there’s a more performant alternative to either operation, give it a name and express it in a function. That’s what functions are for, no?

The biggest problem is that map, filter make copies of the structure. That's an allocation, that means GC calls.

You can make a similar function that changes the data in place and will be faster. But that comes with side effects which is not functional style.

The real problem here with the spec committee.

Lodash is MUCH faster than native because it uses iterators so you aren't actually looping over and over.

We need builtin iterator versions of all these looped functions so it adds an implicit/explicit `.valueOf()` that calls the chain and allocates only one new array.

There are now builtin iterator versions of most of these looped functions [1], should be shipping in stable Chrome next month. The "give me an array at the end" function is spelled toArray.

But it's not going to help all that much with this problem. The iterator protocol in JS involves an allocation for every individual value, and while in some cases that can be optimized out, it's pretty tricky to completely optimize.

It's always going to be difficult to beat a c-style for loop for performance.

[1] https://github.com/tc39/proposal-iterator-helpers/

Yeah, besides Javascript runs to client side so let client deal with bad perf. I am happy writing my beautifully designed readable code.

Javascript also runs on server side.

Reply on news.ycombinator.com