Hacker News Reader

Comment by tomxor | Hacker News Reader

There's a lot to like in modern Javascript, pretty much everything in the list I appreciate.

The only thing I wish was never added is the new Array Functions, I mean, ok they are "handy" sometimes, but they seem to get abused heavily. Newbies like stringing them together and even nesting them, when they could have achieved the same with a single for loop and the same number of lines. In other words they seem to encourage people to artificially increase the complexity of a problem without any objective improvement in legibility, not to mention lots of GC work with throw away arrays... many people don't seem to even be conscious that under the hood of most of the array functions is just another iterator of some kind.

View on HN

Newbies aren't the only ones stringing them together and nesting them, even seniors like me are...to great effect, increased readability and are safer than potentially dangerous mutations.

I teach all my reports to lean heavily into the new array functions because, if wielded correctly, are much more powerful than using for loops while using less code.

The big problem with them is that they are naive. If you string 10 of them together, you will iterate the array 10 times and generate 10 garbage arrays.

Lodash and similar libraries are much better in this regard as they tend to use iterators internally which don't generate all the extra garbage and don't iterate multiple times. Because they don't have to handle all the weird edge cases, they tend to also execute faster too.

It's pretty rare for me to string more than two or three together. If you're chaining 10 together, maybe it is time for a loop.

Computers are fast, and all browsers are really good at this stuff, so I don't tend to worry about creating a bunch of extra work for the GC.

Something something.. premature optimisation?

I’ve always heard premature optimization used to refer to convoluted, harder to use and understand techniques that trade lots of developer time for extra performance.

In this case, we’re talking about a single import and almost identical API while also gaining access to tons of additional and more advanced functions that save time too. It hardly seems comparable.

> premature optimisation

This is the most missused phrase of all. We are not talking about optimisation here, we are talking about _not_ writing slow code, there is a huge difference. Optimisation tends to add complexity with a trade off.

I've usually seen more complexity with single for loops and having complex logic mixed with imperative approach also makes it a lot harder to read.

Array methods convey meaning a lot better. There are some cases where performance matters, but usually the performence cost is negligible.

That is a valid opinion, I agree there are advantages to plain for loops. However, it is not a universal opinion and I would argue against the for-loop, sometimes. Some languages people love do not even have loops.

You never know what structure a for-loop will take, it could break early, skip items, build a new data structure, mutate a data structure, or all the above. If I see a map and a filter, I know exactly what each does.

I don't want to argue over which is better. Pros and cons. I just wanted to say that chaining and nesting array functions is not a reliable sign that someone is a "newbie", maybe they're just someone with different preferences.

A for loop is an imperative construct and can be used to do literally anything. One has to read on into the body of the loop to understand what's going on. Worse, there could be a bug and now you have no idea what the programmer intended. Array.map, on the other hand, only does one thing: turns an array into another array. The intention is clear. It makes a program much easier to understand.

In javascript, what prevents the body of the map function from doing arbitrary stuff? Don't you have to read that to know for sure, just like a for loop?

In some languages the map function may be restricted to not have side effects, in which case I'd agree, but not javascript, correct?

You can't stop bad programmers doing bad stuff. It's not about that. It's about communicating intention. Code as documentation.

There is nothing more clear than code as a way to communicate, at least for me. My writing in English obviously could be better but easier just to show what I mean.

This is correct, but there are some guarantees such as the result will be an array of the same length, mapping function will be called for each element, function itself can be more easily tested in isolation and there are no imperative constructs (creating accumulator array outside of the scope, tracking the index, pushing to the accumulator array)

This lends itself very nicely to functional programming (especially with typescript IMHO)

Many array looping functions have been around since ES5 and I've been personally replacing them to for-of loops with very few exceptions (.map() and .filter() remain handy)

Useful fresh additions are .find() and .includes()

Vectorized array functions are easier for the compiler to optimize than for loops. Once things get nested the performance comparison isn’t even close.

As a standalone idea yes, however in practice this is not actually the case [0], mostly due to those methods having a number of extra checks, more functionality built into them etc.

[0] https://stackoverflow.com/q/21037888/1470607

Fair point, although as the answer states, it depends on use cases. Working with small datasets the performance difference is negligible, but with decently large datasets (~1-100mb) and nested loops the delta is night and day.

I just wish those methods were available on iterators (and return iterators when called on arrays) and a collect method that creates a new array (a bit like Java). That would reduce the overhead and keep the advantages of this functional style.

As someone who works in a few languages I find the array methods really handy as they work similarly. It's usually a bit clearer to me what the programmer's intention was with them rather than a straight for loop.

Depends how big the arrays are. Looping over a 100 item array 3 times almost always has a negligible performance hit but might be more readable

Sure if your entire program is only one loop that iterates over 100 things that fit in an L1 cache.

If you write an entire program with this thinking, a significant program, each of those "negligible performance hits" will usually add up to a poorly performing program. Back in the day people called "optimising" the application of clever algorithms and tricks to squeeze more out of a computer, today we call it ripping all the shitty slow code out of programs because devs couldn't be arsed to write things properly because "computers are fast". </ yes it's a rant, it's why lots of stuff sucks, make nice things pleeease

Reply on news.ycombinator.com