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

Nerdsniping: A glimpse into a stubborn mind

blog.andyet.com

Post reply on HN
Print view View original

41–50 of 94 posts

Re: Nerdsniping: A glimpse into a stubborn mind

#41

Post by briantakita »

mncolinlee wrote: post #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.

> 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.

You get used to this as you get seasoned with javascript. Every language has it's quirks. The human brain is remarkably adaptable to using tools & dealing with intricacies. I personally utilize & appreciate the difference between == and === to reduce complexity in the code. I assume the reader also understands such differences.

I also find automated testing, logging, a module system like commonjs, and linters to be useful when programming in javascript. Once these are in place, systems written in javascript are remarkably maintainable & scale with complexity.

Re: Nerdsniping: A glimpse into a stubborn mind

#42

Post by at-fates-hands »

briantakita wrote: post #41
mncolinlee wrote: post #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.

> 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. You get used to this as you get seasoned with javascript. Every language has it's quirks. The human brain is remarkably adaptable to using tools & dealing with intricacies. I personally utilize & appreciate the difference between == and…

>> I also find automated testing, logging, a module system like commonjs, and linters to be useful when programming in javascript

Except when I use JSLint. Talk about bringing you back to Earth when you think you've done something remarkable with JS.

Re: Nerdsniping: A glimpse into a stubborn mind

#43

Post by chrra »

peterkelly wrote: post #22

And now for exercise 2: Port the solution to Haskell

  newtype X = X (IORef Int)
  instance Num X where
    fromInteger = X . unsafePerformIO . newIORef . fromInteger
  instance Eq X where
    (X a) == (X b) = unsafePerformIO $ do
                       x  a  a == 1 && a == 2
  True
Edit: formatting.

Re: Nerdsniping: A glimpse into a stubborn mind

#44

Post by mfonda »

I think there was a more general question here that was missed: can a == x && a == y ever be true for any arbitrary values of a, x, and y, where x != y.

From a logical point of view, no, this can never be true. I would suspect this can never be true in javascript, and could only be made true in a language where you can override == to always return true.

I think when most developers use the word "never", what they really mean is "never (within the current context)". This makes conversations a lot simpler. Imagine how difficult conversations would be if you always had to qualify never. "This can never be true (assuming a weird valueOf method hasn't been defined and assuming I didn't modify the javascript interpreter to always return true for == and assuming ...)".

Re: Nerdsniping: A glimpse into a stubborn mind

#45

Post by tonyarkles »

mfonda wrote: post #44

I think there was a more general question here that was missed: can a == x && a == y ever be true for any arbitrary values of a, x, and y, where x != y. From a logical point of view, no, this can never be true. I would suspect this can never be true in javascript, and could only be made true in a language where you can override == to always return true. I think when most developers use the word "never", what they rea…

Here's a JavaScript example, based on what was in the article.

    var b = {c:0};
    b.valueOf = function() { this.c++; return this.c; }
    b == 1 && b == 2
    > true

Re: Nerdsniping: A glimpse into a stubborn mind

#46

Post by nmrm »

resu_nimda wrote: post #32
nmrm wrote: post #24

Earlier quoted context omitted.

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'…

Which claim is that, exactly? And are you implying that the author's original solution is more indicative of real programming? Both solutions work the same way - when accessing the value of "b" for the first check, b is mutated such that the next check will return a different value. Both of them are equally bad practices. The == vs. === issue is the part that's actually irrelevant, it served as a red herring.

> Which claim is that, exactly? A

"This difference in how syntax is understood actually presents a barrier to programming for modestly trained mathematicians, who would otherwise be expected to excel."

> And are you implying that the author's original solution is more indicative of real programming?

Well, neither is... but yes, overriding == or .equals is somewhat common.

> when accessing the value of "b" for the first check, b is mutated such that the next check will return a different value.

The difference is that you could easily imagine a sane example where x == y != x === y, whereas it's hard to imagine a situation where I would want to override get (or ==) with a method that mutates the requested variable.

> The == vs. === issue is the part that's actually irrelevant, it served as a red herring.

For the claim re: syntax and compatibility with mathematician's expectation, it's exactly the other way around.

FWIW I feel the quoted claim re: syntax claim is interesting, whereas the contents of the article (summarily, "you can override == or .get and cause crazy stuff to happen") is unsurprising and kind of silly to most programmers even moderately experienced with OOP in dynamic languages (for the reasons given in this post and others -- everyone knows about it, it shouldn't take 11 days to figure it out, and in practice no one does purposefully obscure stuff like mutating values when == or .get is called).

edit: grammar

Re: Nerdsniping: A glimpse into a stubborn mind

#47

Post by mfonda »

tonyarkles wrote: post #45
mfonda wrote: post #44

I think there was a more general question here that was missed: can a == x && a == y ever be true for any arbitrary values of a, x, and y, where x != y. From a logical point of view, no, this can never be true. I would suspect this can never be true in javascript, and could only be made true in a language where you can override == to always return true. I think when most developers use the word "never", what they rea…

Here's a JavaScript example, based on what was in the article. var b = {c:0}; b.valueOf = function() { this.c++; return this.c; } b == 1 && b == 2 > true

That only works for consecutive integers, not any arbitrary values.

Re: Nerdsniping: A glimpse into a stubborn mind

#48

Post by rmrfrmrf »

mncolinlee wrote: post #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.

There are ways to do stupid things in any language. I don't think anyone would ever tell you that redefining an integer as an object and overwriting its prototypes is an acceptable way to solve...any? problem.

Re: Nerdsniping: A glimpse into a stubborn mind

#49

Post by lmkg »

mfonda wrote: post #44

I think there was a more general question here that was missed: can a == x && a == y ever be true for any arbitrary values of a, x, and y, where x != y. From a logical point of view, no, this can never be true. I would suspect this can never be true in javascript, and could only be made true in a language where you can override == to always return true. I think when most developers use the word "never", what they rea…

I think there are a few cases of non-transitive equalities in JavaScript, specifically around falsey values. Part of it also has to do with whether x is the right-side input or the left-side input, because that changes type coercion rules.

Aha, found one:

  ['0'] == 0
  > true
  [0] == 0
 > true
  [0] == ['0']
 > false
Transitivity of equality can also never be relied upon when dealing with Floating Point numbers. This is correct and unavoidable behavior, but still surprising to many developers.

Re: Nerdsniping: A glimpse into a stubborn mind

#50

Post by tyilo »

mikeash wrote: post #39
maxbucknell wrote: post #31

Earlier quoted context omitted.

At the end of the article, it is demonstrated that this can happen even with strict equality by overriding the getters. Any language with getter/setter support can do this. Operator overloading can be used for even nefarious ends. The point is that side effects in code are dangerous, and can be used to mislead a reader. If this happens, it is not the fault of JavaScript. Anyone who writes code like that for purposes…

Not all languages with getter/setter support will invoke them automatically like this. For example, it's not possible in Java or Objective-C to make an expression of the form a == b, where a and b are plain variables, have any side effects.

In Obj-C you can if you would allow `a.prop == b.prop`.
Post reply on HN