Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Return True to Win

alf.nu

Post reply on HN
Print view View original

111–120 of 123 posts

Re: Return True to Win

#111

Post by fennecfoxen »

xeniak wrote: post #24
idbehold wrote: post #20

Let me document all the reasons I dislike the HTML spec: it defines a willful violation of the ECMAScript standard.

Can you elaborate?

I'll use a link shortener to prevent spoilers. This link elaborates exactly which rules are abused: https://goo.gl/mu5xtr

"These requirements are a willful violation of the JavaScript specification current at the time of writing. The JavaScript specification requires that ToBoolean return true for all objects, and does not have provisions for objects acting as if they were undefined for the purposes of certain operators. This violation is motivated by a desire for compatibility..." with old Internet Explorer.

Re: Return True to Win

#112

Post by fennecfoxen »

idbehold wrote: post #52
lalala1995 wrote: post #3

Please more levels

You've already finished wat, undef, random3, and random4?

> wat, undef

Oh, undef is as easy as knowing HTML trivia. Getting a falsey value to return an arbitrary string when invoked as a function is at least a little harder...

> random3

... is almost as easy as random1

> random4

is exactly as impossible as it looks

Re: Return True to Win

#113

Post by twblalock »

andrepd wrote: post #91
Kapow wrote: post #82

Earlier quoted context omitted.

JS gets even weirder when you include all the comparison operators. https://jsfiddle.net/5Yzs6/17/ Did you know undefined is equal to undefined, but not = undefined? Or that two instances of the same object/array are not equal (e.g. [-1] != [-1]), but are both = each other? Or that /.*/ is non-comparable (only != is true) to all numbers, but greater than [-0.5] and "-0.5", and less than [0] and "0"?

What a clusterfuck.

And yet, people say Brendan Eich doesn't believe in equality!

Re: Return True to Win

#114

Post by pselbert »

liquidise wrote: post #54
fauria wrote: post #21

This table is quite useful to solve some problems: https://dorey.github.io/JavaScript-Equality-Table/

> Moral of the story: Always use 3 equals unless you have a good reason to use 2. NaN === Nan // => false [] === [] // => false {} === {} // => false [1] === [1] // => false [0] === [0] // => false I guess i never see the gains in the triple vs double equal sign wars.

This notion of equality would make pattern matching on empty lists or objects impossible in languages such as Erlang or Haskell. Perhaps it makes sense with the knowledge that each array is a different object, but it is highly counterintuitive.

Re: Return True to Win

#115

Post by omaranto »

The link points to a page that only contains the text "return true to win" in large type on a white background. As with most modern art, I don't get it.

Re: Return True to Win

#118

Post by astrobe_ »

Zarel wrote: post #103
astrobe_ wrote: post #93

Earlier quoted context omitted.

Does that spec forces you to implement equality test between floating point numbers?

...yes? I'm not sure exactly what you're asking here, though.

I'm asking if it is really a good idea for a language to provide equality/inequality for floating point numbers when it's often mistake to do that.

Re: Return True to Win

#120

Post by Myrmornis »

astrobe_ wrote: post #118
Zarel wrote: post #103

Earlier quoted context omitted.

...yes? I'm not sure exactly what you're asking here, though.

I'm asking if it is really a good idea for a language to provide equality/inequality for floating point numbers when it's often mistake to do that.

So disallow the direct operator but allow equality to be deduced indirectly by usage of > = <= ?
Post reply on HN