Is (3 / 0) == (4 / 0)?

Is even (3 / 0) == (3 / 0)?

EDIT:

also, see [1] on what becomes when dividing both sides of equation by zero and assuming equality still holds. Essentially, both sides become NaNs and everything is possible -- up to and including 1 == 2. Now that'd would be odd, should it happen in your program.

[1] http://en.wikipedia.org/wiki/Invalid_proof#All_numbers_equal...

[1]: http://en.wikipedia.org/wiki/Binary_relation

I have to respectully disagree with you :-)

Consider for a moment ``3 + 0''. That expression (those three tokens) denote something we can talk and reason about. Now the important point: not because of some inherent property of the notation itself, but because we, the people, agreed what we mean by that expression.

Contrast that with expression ``3 / 0'' -- which does not denote anything. Maybe, just maybe, there is something usefull that stems from division by zero, but! so far, we have not agreed upon what would be denoted by division by zero. We haven't agreed upon anything this expression would mean. It denotes no single thing, and neither a (nonempty) set of things. Of course, we have to somehow describe the fact of ``having nothing to say'' -- we use `NaN' -- but that's not a number symbol, that's a meta-symbol. Means, ``nothing to see there, my dear CPU, please move along''.

Note also, how in SQL, the following does not hold true: NULL = NULL. In SQL, `NULL' doesn't stand for something, but for no thing at all. And whaddya know, division by zero yields NULL in SQL.

* * *

As for the equality itself (as opposed to assignment), so far we, the programmers, have only one common use for it -- checking whether data from some source ``equals'' data from another source. There are three common ways of doing that:

0) pointer equality. Fastest, simpliest, but won't suffice in some programming languages. Thing is, one kind of languages keep just single copy of all the same values (say, every variable that holds string "foobar" points to the same memory cell), but others do not, and here you need one of the two following ways.

1) value equality (== in JS): whether the two expressions ``evaluate'' to the same value. This has two downsides: is generally slower (the overhead of runtime evaluation), and often is governed by twisted rules reagarding type coercion. For example, in PHP, the following holds: 0 == "1". Fun fact to know and tell: those twisted rules stem from the language creators' desire to make programming easier.

2) type-and-value equality (=== in JS): this straightens some ofthe twisted rules of 1), due to comparing data types first (instead of prerforming type coercion), but otherwise does the same thing: compares value. May often be faster and also simplier to grasp, but also may blow up when you mix up data with different types. Which nb. is easy to overlook when data comes from data sources having different semantics or idioms.

To put 1) and 2) in another way, those operations compare two values by their properties. Yet the NaN doesn't have properties to speak of, because it is not a value in the first palce. The operation of comparing is thus not well defined for NaN. Oops? :-)

You said this, but you never seemed to get around to an actual point of disagreement that I could see.

I'm not sure you realized that I was talking about math equality. In math, there is no distinct "3" vs. "3 + 0". We can indeed talk about how they are different tokens but there's no second "3". There's just the one in conventional systems that most people have heard of, expressable in a countably infinite number of ways (without getting crazy).s

(Yes, I know some of the other ones. That's why I said "conventional systems", after all.)

Math equality not being the same as programmer equality was my entire point. Thanks for elaborating on that theme, I guess? And given that it isn't the same thing, we aren't particularly constrained in how we use our programmer equality except by practical considerations. If we want NaN to == NaN and not === NaN, it's just a matter of making the programming runtime do it. Or vice versa. Or we can simply crash, which actually given how frequently people actually want NaN in Javascript is probably actually the choice I would choose. We aren't constrained by how continuous mathematicians of a certain school think our numbers work, because as programmers we never work with those numbers. We have completely different things going on. Actually if you operate on the assumption that your computer numbers are like mathematician numbers you will be in for nothing but pain on both sides.

    var someVar = 'hello';
    setTimeout((function() { alert(someVar); })(someVar), 1000);
    var someVar = 'goodbye';

    var someVar = 'hello';
    setTimeout(
        (function(innerVar) {
            return function() { alert(innerVar); };
        })(someVar),
        1000
    );
    var someVar = 'goodbye';

You can not “fake” scope. When you call `call` on a function and pass an object as an argument, you are calling the function as a method of that object. This has nothing to do with a function’s scope.

Vote for articles you feel contribute to HN, either directly or through their discussion (a vote for a post does not necessarily imply agreement, it implies "This is worth reading.")

Please:

Point out half-truths and misconceptions.

Please don't:

Ask other people to vote for or against a post or comment.

What alert() does is an implicit conversion to string, and that is surprisingly defined to say "object" in ECMA standard. Could be matter of backward compatibility...

You get this in most other programing languages too.

> 8. Firefox Reads and Returns Colors in RGB, Not Hex

The title says JavaScript, this is the DOM.

> 7. Functions Can Execute Themselves

Why is this so odd? I feel the author is too biased towards other languages. Also his example totally misses to point of closures.

> 6. You Can Fake Scope

No you can't fake scope, you override it. Why is this so odd? Again the author is not looking at it correctly, this is natural if you use it correctly.

Most of this article seems to come from someone who didn't really use JavaScript a lot, hence there is a lot of bias and prejudice. All you need to do is tell yourself that classical OOP is not the only way to code, and you will see that most of those things are really good stuff and not oddities.

edit: JavaScript arrays are odd in general since they are just objects designed to look like "true" arrays. I guess I'm so used to that now that nothing about them feels "odd" anymore.

  function a() {
    return
      true;
  }

    def a():
        return
        False;

    def foo
     return
     true
    end

  var a =
  42

Javascript just happens to make assumptions with certain kinds of ambiguities, but then, all programming languages do.

http://bclary.com/2004/11/07/#a-7.9.1

Thanks for the reference. I still think this is a general issue, and calling it semicolon insertion confuses the issue :\