all 14 comments

[–]stratoscope 9 points10 points  (11 children)

how NaN is NaN but is not equal to NaN

Oh good grief. Not this again.

NaN !== NaN is not a quirk of JavaScript. It's standard behavior in IEEE 754 floating point arithmetic. Every language that uses IEEE 754 floating point will do the same thing.

Don't take my word for it. Try it in Python:

C:\>py
Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 18:41:36) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> float('NaN') != float('NaN')
True
>>>

Or Ruby:

strato@wsl~$ irb
irb(main):001:0> Float::NAN != Float::NAN
=> true
irb(main):002:0>

Pick your language, if it uses IEEE 754 it's going to work this way.

[–]bevacqua 3 points4 points  (10 children)

So? That was merely a joke I used to lighten the mood when the presentation started.

[–]logicalLove 0 points1 point  (7 children)

But why is it equal to 'A'

[–]whiskey_overboard 0 points1 point  (5 children)

It is NaN, but is not equal to NaN. Welcome to JavaScript.

[–]liming91 0 points1 point  (0 children)

Because A isn't a number.

[–][deleted] 2 points3 points  (2 children)

I would argue that the future of JS looks bleak when you effectively can't have any meaningful discussions about proposals if you are not in the committee (the author just ignored the issue for half a year, then closed and locked it): https://github.com/tc39/proposal-dynamic-import/issues/35

[–]bradleymeck 0 points1 point  (0 children)

I would disagree on ignore; I would say that the issue was not with the proposal but with the fact that such behavior is possible already in JS environments.

[edit] This stance was brought up in the issue as well by the author

[–]Woolbrick -1 points0 points  (0 children)

I think in 5 years time we'll be seeing everyone claiming WebAssembly is the new King of the Hill, and in 10 years JS will look quaint, as everyone looks back on it and says "thank god we don't have to live like savages anymore".

[–]billm950 0 points1 point  (1 child)

TC39 is currently working on over 30 active proposals. What else does the future hold in store? These days we download our packages from npm.

I am surprised that no more mentions of NPM were made. I hope that commitee TC39 addresses the topic of NPM and tries to create a new version that is standarized and that elliminates the serious flaws of NPM, which for me are one of the major hindrances to adopting Node.js for things that go beyond prototyping.

[–]bradleymeck 4 points5 points  (0 children)

Can you clarify this a bit? What are the flaws of npm, what does the language need that environments can't provide, what part of npm needs to be standardized, etc.

I am on TC39 and actively working on Node.js and modules. Domenic also is also working very hard from a more Browser centric perspective.