Live data from Hacker News

Nerdsniping: A glimpse into a stubborn mind

blog.andyet.com

21–30 of 94 posts

Re: Nerdsniping: A glimpse into a stubborn mind

#21
post #12

Earlier quoted context omitted.

> If anything, mathematicians are incredibly used to overloaded equals operators. That's my point. The == sign meaning many things is unsurprising (and key to this "hack"), whereas explicitly using two different symbols for equivalence in the same expression is a huge, glaring signpost to pay attention.

As demonstrated in the postscript, it can still be accomplished when the symbols are all the same. So that difference is not the key to the hack. As ronaldx noted, the key is that a variable can change value in between two equivalence evaluations within a single statement.

Arguably the thing that tripped me up for the majority of the time was latching on to the fact that == and === are different, and trying to _always_ satisfy the two conditions, rather than just spotting that I can change the reference to b from within the first valueOf call. I'm not sure how much I'd read into the "if I was more of a mathematician and less of a dumb programmer this would have been solved trivially" argument.

Re: Nerdsniping: A glimpse into a stubborn mind

#24
post #12

Earlier quoted context omitted.

> If anything, mathematicians are incredibly used to overloaded equals operators. That's my point. The == sign meaning many things is unsurprising (and key to this "hack"), whereas explicitly using two different symbols for equivalence in the same expression is a huge, glaring signpost to pay attention.

As demonstrated in the postscript, it can still be accomplished when the symbols are all the same. So that difference is not the key to the hack. As ronaldx noted, the key is that a variable can change value in between two equivalence evaluations within a single statement.

The postscript is irrelevant to the claim made in the original post on this thread. It's a conflated example and not indicative of real programming.

if "get" returns different values when called multiple times within a single expression, one of two things must be true: * Someone's overriding "get" with a mutation to the variable. In all but the very rarest of circumstances, that someone should be publicly shamed. It's a nice hack for the purpose of the article, but not real code. * there's some very fine-grained concurrency. This case is irrelevant to the OP's claim because concurrency of this sort is very likely a fundamental characteristic of the system at hand, and never an artifact of the language.

Re: Nerdsniping: A glimpse into a stubborn mind

#25
Nerdsniping reminds me of the Walt Whitman poem:

   There was a child went forth every day;
   And the first object he look’d upon, that object he became;
   And that object became part of him for the day, or a certain part of the day, or for many years, or stretching cycles of years.
It's especially bad if you'd really rather be doing something other than what you're currently doing.

Re: Nerdsniping: A glimpse into a stubborn mind

#27
And this is why Javascript can be such an awful language. Leaving off a single equals has such a profound effect, often without a new coder even realizing it while reading the code.

Imagine what happens to your code when someone tries to write a function for its side effects similar to the example seen in the blog post. Then releases it in production for it to break in six months with a feature change.

Re: Nerdsniping: A glimpse into a stubborn mind

#28

Earlier quoted context omitted.

As demonstrated in the postscript, it can still be accomplished when the symbols are all the same. So that difference is not the key to the hack. As ronaldx noted, the key is that a variable can change value in between two equivalence evaluations within a single statement.

Arguably the thing that tripped me up for the majority of the time was latching on to the fact that == and === are different, and trying to _always_ satisfy the two conditions, rather than just spotting that I can change the reference to b from within the first valueOf call. I'm not sure how much I'd read into the "if I was more of a mathematician and less of a dumb programmer this would have been solved trivially" a…

If a == b iff a === b, then == ~ ===. If == and === are different (which they presumable are, because otherwise we would only use one symbol) then by definition there exist counter-examples of the thing you were trying to _always_ satisfy.

In other words, it would never even occur to a mathematician to make your mistake...

More to the point, a mathematician wouldn't assume that some arbitrary predicate that you are allowed to define at will behaves the same way as a system-defined equivalence operator.

Edit: Added last paragraph and readability changes. Also, ~ is another symbol for equality, this time equality over binary relations.

Re: Nerdsniping: A glimpse into a stubborn mind

#29

"I want my code to execute if port is 80 or 443, and http is false" Couldn't you simply do this?: if ((a==='80'||b==='443') && http===false) { ... }

I think the goal was if (a==='80' || (b==='443'&&http===false)) {...}

Either way, it's called "Boolean Logic" and as far as I knew every Computer Scientist had to take this class in college...Not sure how you could get a job as a programmer without understanding that...
Post reply on HN