Nerdsniping: A glimpse into a stubborn mind

Yikes. I understand that companies use these posts as a form of advertising, but seeing your "application security specialist" struggling with such a basic expression gives me pause.

I was working with this guy - he always tried to prove that everything is possible wasting time. He ALWAYS over-complicated simple things. He was horrible to work with and everyone hated him.

Not to say you are just like him etc. but this post reminded me of him because it was probably exactly what he would do.

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.

The differences between programming syntax and elementary/Boolean algebra are very awkward to understand clearly and deal with correctly. We clearly understand mathematical algebra to work one way, and we naturally assume programming algebra works the same way, which it doesn't at all.

Here, the antagonist says that b can't be 1 and 2 at the same time, which would be self-evident in mathematical algebra, but turns out to be quite irrelevant to Javascript and to programming paradigms generally (since two statements will never be checked simultaneously).

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

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.

"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) { ... }

Call me nitpicky, but it always bugs me when someone references some content, but doesn't link to it. Specifically the XKCD and Stackoverflow links. Link to the comic and question specifically, rather than making me go hunt for that content.

> I guess we’ve messed with the prototype too much, and JavaScript isn’t really convinced it’s still a proper number anymore.

You're comparing a literal number with an object, which are not the same type.

  2 === new Number(2)
  // => false
  2 == new Number(2)
  // => true

> Have I learned anything directly useful?

You probably haven't. But a less experienced programmer has learned why you should always use ===.

Might not be Java but still interesting, it made me think of one of my favorite little quirks in C++:

  #include <cmath>
  
  //Floating point model: Strict:Precise:Fast
  //Will code execute
  float a = nanf("");
  if (a == a)//S:No P:No F:Yes
      (do something);

  if (a != a)//S:Yes P:Yes F:No
      (do something);

  if (a < 0.f || a > 2.f)//S:No P:No F:Yes
      (do something);

  if (isnan(a))//S:Yes P:Yes F:Yes
      (do something);

NaN's (Not A Number) can propagate a long way through your code, possibly reaching places where they cause real problems. When dealing with input, especially networking, one should always check for NaN's. Basically the rule with NaN's is: The comparison always returns false if any NaN is involved. But as you can see; specifying the fast model throws that out of the window. (Code was otherwise unoptimized.)

In the third statement an otherwise fine check is done to make sure the value in a is sane, it doesn't get changed but its certainly not what you'd want it to be.

Whole lots of fun can be had when serving this to game servers. :D

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

It's not often I see an HN thread which so aptly demonstrates the exact effect under discussion.

var i=0;

var b = {};

b.valueOf = function () {

  return ++i:

};

if (b==1 && b==2) {//success}

And so far everyone has missed telling the poor OP how to avoid writing two equality checks...

    if( [80, 443].indexOf(port) !== -1 && http === false )

This kind of abuse is also available in Python!

    In [3]:
    class TheObjectThatIsEqualToAnything(object):
        def __eq__(self, other):
            return True

    In [4]:
    x = TheObjectThatIsEqualToAnything()

    In [6]:
    x == 3 and x == 5
    Out [6]:
    True

I think the answer to "can something be fuzzy equal to one value and strictly equal to another in JS?" has an easy answer that doesn't take much effort to find. This might be cooler in another language, though.

var b = 2;

b == '2'; // true

b === 2; // true

And here we all are reading this post during work hours. My god, the amount of productivity lost because of that simple question in chat!

Is this a case of readability versus theoretical perfection?

0.25 = 0.25

1 - 3 + 2.25 = 4 - 6 + 2.25

1^2 + 2(1)(1.5) + (1.5)^2 = (2)^2 - 2(2)(1.5) + (1.5)^2

Since a^2 - 2ab + b^2 = (a - b)^2

(1-1.5)^2 = (2-1.5)^2

1 = 2

QED.

And now for exercise 2:

Port the solution to Haskell

so...

(everything == all && all == everything) == stardust/code

Defining a number to be a procedure (or 'word' in the parlance) is simple in Forth.

> : a 2 ;

> : 2 3 ;

> a 2 =

> a 3 =

The two flags on the top of the stack are now equal.

This took you 11 days?!