Isn't it or is it not?
-
Technology update news everyone! Coffeescript is still horrible shit. In what fuxing universe would these three operators not yield identical results? Everyone associated with the CS compiler should be flogged with awful things.
-
if 1 isnt 2 console.log("hello world") if 1 is not 2 console.log("hello world") if 1 != 2 console.log("hello world")
is the same as
if 1 isnt 2 console.log("hello world") if 1 is (not 2) console.log("hello world") if 1 != 2 console.log("hello world")
due to operator precedence
Disclaimer: Never seen CoffeeScript beforer today.
-
Assuming the issue lies here:
if 1 is (not 2) console.log("hello world")
(not 2)
should be an error, or anything other than 2 should compare equal to(not 2)
. Having(not 2)
be any specific value is stupid.
-
But the javascript part isn't editable, only what I assume is the CoffeeScript part is (plus putting two things side by side I assumed the input one would be on the right instead of on the left).
-
if 1 is not 0 -> if 1 is (not 0) -> if 1 is true -> false if 1 is not 1 -> if 1 is (not 1) -> if 1 is false -> false if true is not 0 -> if true is (not 0) -> if true is true -> true if true is not 1 -> if true is (not 1) -> if true is false -> false
1 and 0 are evaluated as the traditional true and false, except they aren't equal to true and false.
So when you use the not operator on a number, it evaluates 1 as true, then nots true, and it evaluates 0 as false, then nots false, giving false and true respectfully.But since
(1 is true or 1 is false) -> false
,(1 is not [any int value]) -> false
-
I didn't even try to edit the one on the right. Thought it was a read only example. Which confused me as to why
if (1 !== 2)
was translated two different ways.
-
Assuming the issue lies here:
if 1 is (not 2) console.log("hello world")
(not 2)
should be an error, or anything other than 2 should compare equal to(not 2)
. Having(not 2)
be any specific value is stupid.At the end of the day, it's JavaScript, where everything is truthy or falsey
-
due to operator precedence
I've said it never and I'll say it again - operator precedence exists only to confuse the hell out of people...
...and make code a little neater, I guess...
These are apparently and actually equivalent in Clojure(Script):
(not= 1 2) (not (= 1 2))
And the
=
function doesn't do any stupid-ass-fucking-retarded-frustrating-as-shit-not-helping-at-all type coercion.
-
If you're going to make a language to fix javascript, fix javascript's actual problems don't just add some syntax sugar!!!
*coughTypeScript*cough…and you deleted that bit of your post…
-
More dumb shit inherited from javascript
JavaScript, where everything is truthy or falsey
Anything can be compared to anything is the problem.
But as soon as you use a logical operator on a number it evaluates whether the number is 0 false, anything else true. But then it casts to a boolean, and from then on every equavilance of a bool to a number is false.
-
operator precedence exists only to confuse the hell out of people
Are you one of those people who gets facebook questions like
What is 1 + 40 * 0 - 40?
wrong?
-
Having (not 2) be any specific value is stupid
Next time you'll tell me "2 and 1" and "2 and 3" should be the same, too...
-
Are you one of those people who gets facebook questions like
What is 1 + 40 * 0 - 40?
wrong?
No, but I think fewer people would get it wrong if it was
(1 + (40 * 0)) - 40
.Assuming they know what the parenthesis mean.
-
No, but I think fewer people would get it wrong if it was (1 + (40 * 0)) - 40.
Assuming they know what the parenthesis mean.
It's not as if it's not taught extensively in grade school; there's no real excuse for someone who's not mentally damaged to not learn it.
-
That's as bad as abbreviated conditionals in COBOL...or, wait, maybe it isn't.
-
No, but I think fewer people would get it wrong if it was (1 + (40 * 0)) - 40.
Your outer set of parenthesis is redundant. Even if you messed with the precedence rules, all these:
(1 + (40 * 0)) - 40 1 + (40 * 0) - 40 1 + ((40 * 0) - 40)
give the same result.
-
-
It's not as if it's not taught extensively in grade school; there's no real excuse for someone who's not mentally damaged to not learn it.
They teach CoffeeScript operator precedence in grade school?!
You see, when having a conversation, you can't evaluate every statement independently. You have to consider what was said earlier as well. I said that I though having to remember operator precedence rules was confusing. My subsequent statements about making a simple arithmetic expression less likely to be misunderstood by adding extra parenthesis is part of explaining or supporting that thesis. The conversation doesn't change subject every single post.
I was not claiming that arithmetic operator precedence was too confusing. I was just building on your metaphor. You only need to learn arithmetic operator precedence once. But every programming language has it's own syntax rules. Some you will need to learn quickly. Some you will only use for a brief time. It's confusing to have a hundred different sets of subtle, implicit syntax rules. So my suggestion was that we design languages to have a minimum of syntax rules.
That is all.
-
I was just building on your metaphor.
But what if @FrostCat's metaphor is made of sand? You don't want to build on sand; the wise man (and Boomzilla) builds his house upon the rock. The lawn can go on the sand.
-
-
[QUOTE]What is 1 + 40 * 0 - 40?
42
[/quote]I knew there was something fundamentally wrong with the universe.
-
1 + 40 * 0 - 40
i know several languages that by design would answer
-40
no operator precedence, nor parenthesis. strict left to right evaluation.
-shudder- i hate working in that part of the code base. and it's working so there's no budget for a rewrite (and justifiably so. the things old enough it would take years to rewrite to the point that it works exactly the same as it does today)
-
@FrostCat said:
1 + 40 * 0 - 40
i know several languages that by design would answer
-40
I know a language that by design would answer '-1599'.
APL
-
Right-to-left evaluation?
-
(not 2) should be an error
Unless you love C so much you replicate all its misfeatures in scripting language you develop.anything other than 2 should compare equal to (not 2)
Depends on what "not" means. Usually, it means logical negation. Typically, the operand of logical negation must either be bool, orcastedconvertible to bool. So "not 2" is pretty much equivalent to just "false", and "1 is false" is obviously false.
-
Unless you love C so much you replicate all its misfeatures in scripting language you develop.
There's what you might wish to do, and there's what you have to do for expediency's sake. It's not that big a deal in practice though; just don't let
=
be assignment…
-
What is 1 + 40 * 0 - 40?
You have to take care with this one. 40 to the -40 power is a very small number (around 8.27E-64), and most floating point hardware will evaluate 1+(40 to the -40 power) as 1.http://en.wikipedia.org/wiki/APL_(programming_language)
The expression is equivalent to 1 + (40 ** (0 - 40)) in languages that have ** as an exponentiation operator, or to 1 + pow(40, 0-40) in C or C++.
APL's expression evaluation order is a pretty heavy .
-
@accalia said:
@FrostCat said:
1 + 40 * 0 - 40
i know several languages that by design would answer
-40
I know a language that by design would answer '-1599'.
APLYou're wrong. * is exponentiation, not multiplication. And you need a different glyph to indicate negative 1599 - what you have there is still an expression using the monadic negation operator, thus "negate 1599". The glyph you need is "high minus", so that your (wrong) result would be written ¯1599.
-
Right-to-left evaluation?
Exactly. With parentheses to override that order, of course.And the fucking stupid fucking pink fucking multireply fucking box can fucking fuck the fucking fuck off. Stupid sodding thing.
-
The expression is equivalent to 1 + (40 ** (0 - 40)) in languages that have ** as an exponentiation operator
Sure, if you misread * (multiplication) as ** (exponentiation).
-
No, no no, no. Surely it's negative sixteen hundred and forty! That is, forty one times negative forty. Right?
Filed under Brackets Of Divide Minus Add Star?
-
Sure, if you misread * (multiplication) as ** (exponentiation).
APL uses × for multiply and * for exponentiation. TIL that APL is
-
APL uses × for multiply and * for exponentiation.
I thought it might be something along those lines. See, I was writing in English, not APL, though.
-
See, I was writing in English, not APL, though.
English doesn't use * for multiplication either.
-
Not when handwritten; when typed though, it's a lot more common
-
-
I don't see that on my keyboard (or any keyboard I've ever used)
And yes, I know how to type it
-
It is between z an c
-
That's
x
, not×
-
Does this count as a keyboard?
-
Not when handwritten
Speak for yourself. My handwriting is atrocious, so in school I started writing multiplication symbols as * so they could be clearly distinguished from x the variable.
-
In Poland, we use · for multiplication. Problem solved!
-
That's just a really small *
-
No, it isn't. I learned about it in grade school CS class where we had to write maths in Word - I used * instead of · and got my mark lowered.
-
-
You do realise that you're also totally oppressed in that you can't use
+
for multiplication either. When will the mathematical fascism end?
-
You do realise that you're also totally oppressed in that you can't use + for multiplication either.
#include <iostream> class Integer { int val = 0; public: Integer(int i): val(i) {} operator int() { return val; } Integer operator+(Integer rhs) { return val * rhs.val; } }; int main() { Integer a = 2, b = 3; std::cout << a + b << std::endl; }
-
Keep that shit in the evil ideas thread
-
In Poland, we use · for multiplication. Problem solved!
I did that for a while, too.
Then you get into matrix multiplication or set theory or whatever, where it means something else.
-
Then you get into matrix multiplication or set theory or whatever, where it means something else.
Usually it's not a problem because you can omit the multiplication 99% of times anyway.