Hacker News Reader

Comment by VeejayRampay | Hacker News Reader

Javascript. The language where you can reimplement basic functions such as map, each, reduce (which by the way are still available for objects in 2014) and have them be faster than their native counterparts.

It might be that I don't particularly like the language. but it's kind of frightening that we're building the world on that stuff.

View on HN

An alternative interpretation might be - JavaScript, the high level language language that's so awesome that it can out perform native code*

* as long as you make it do less work

Why isn't the native version doing less work? Isn't that what you expect from a language design, that the native version will be as close to optimal as possible in the first place?

Did you read the article? These functions are not 100% equivalent.

Fair enough. Why doesn't the title of the post say so then? "Faster incomplete versions of Javascript native functions" would have been a better summary.

Or even discuss the fact that if this library is good enough for people to use then maybe the edge cases that the native versions are covering might not be so useful after all?

The native versions have to/should 100% support the language spec and historical behavior. In this instance, it means they can't optimize much that iterates over a sparse array.

That's not really fair, the author of this implementation is non-complainant with the spec by dropping edge cases in order to achieve these improvements.

The number of uses we put Javascript to is indeed frightening, given its "fragile" nature and heavy criticism it attracts every now and then.

There is a great, amusing, borderline sci-fi talk by Gary Bernhardt about the future of Javascript and traditional languages compiled to Javascript. My recommendations: https://www.destroyallsoftware.com/talks/the-birth-and-death...

A lot of it has to do with crossing boundaries between C++ and the JIT'd code and losing things like inlining. Doesn't really have to do with JS warts.

This would likely get even faster if you manually specialized a map/forEach/etc for each caller, but then you might as well just write the loop out by hand: http://rfrn.org/~shu/2013/03/20/two-reasons-functional-style...

Pfft. It's not as bad as you imagine.

Reply on news.ycombinator.com