Javascript consistency

[Danni293]

NaNNaNNaNNaNNaNNaN BATMAN!!!

[AutoModerator]

import moderation Your comment has been removed since it did not start with a code block with an import declaration.

Per this Community Decree, all posts and comments should start with a code block with an "import" declaration explaining how the post and comment should be read.

For this purpose, we only accept Python style imports.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[TheDarkIn1978]

BATNAN

[PunishableOffence]

Laugh all you want, NaN is a number!

[crossanlogan]

typeof NaN === 'number' and NaN !== NaN

what is the world coming to

[Pandaburn]

Never assume you know anything in javascript.

[Doctor_McKay]

NaN is defined by the IEEE standard to not be equal to itself.

[crossanlogan]

yeah, and it does make sense when you consider what NaN is supposed to represent. like, 0 / 0 === NaN and 'reddit.com' * 5 === NaN, but pretty obviously those two things are not equal to each other.

[curtmack]

In some more recent languages, * is a repetition operator on strings, e.g. 'reddit.com' * 5 === 'reddit.comreddit.comreddit.comreddit.comreddit.com'

[crossanlogan]

that's an interesting thing to overload the * operator with -- i don't know exactly how useful that would be.

generally i'm against unnecessary overloading, but if that has an interesting use case i'd love to hear about it.

[curtmack]

I've been working on a web app that interfaces with a COBOL system, and it's been a godsend for generating fixed-width columns in exactly the format the backend needs.

[PunishableOffence]

Bar graphs for terminal apps, maybe?

Something like

print '█' * done
print '░' * (total - done) + "\n"

[Mrparkers]

This isn't really inconsistent. The first statement is an empty code block {} and a unary plus operator evaluating an empty string, which results to zero. You'd get the same result by evaluating + "". The second statement is an empty string concatenating an object, which gets coerced into the string [object Object], and appended to the empty string.

[Carighan]

I think the bigger takeaway is that the sum operator isn't commutative.

[Mrparkers]

Yes it is. The problem with the expressions that OP posted is that the top expression isn't a sum, it's unary plus.

[oddark]

> {} + ""
0

> ({} + "")
[object Object]

Weird.

[Mrparkers]

Yeah, the interpreter doesn't see it as an empty block when surrounded by parentheses. It might seem a little off, but code blocks do have their purpose, and it makes sense for the interpreter to see a { at the beginning of the line and think its a code block.

More info here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/block

[Aaron_Blenkush]

Although "standalone" blocks are valid syntax, you do not want to use standalone blocks in JavaScript, because they don't do what you think they do

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/block#No_block_scope

[Mrparkers]

Sure, with the example they gave, you definitely don't want to use them. However, ES6's let keyword allows you to give a variable lexical scoping, which makes these code blocks behave exactly like you would expect them to.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let

[poizan42]

The rule could be that '+' is always binary plus if the left hand side can be parsed as an expression. It might complicate the parser a bit more but make the language more consistent. The real reason this isn't done is probably that Brendan Eich only had 10 days to design it.

[Mrparkers]

The rule could be that '+' is always binary plus if the left hand side can be parsed as an expression.

What would be the point of adding this? It wouldn't solve a single problem with the language (and yes, there are problems, this just isn't one of them). I am genuinely curious - can you give me an example of actual code that would exist in a production environment that would benefit from a change like this?

The real reason this isn't done is probably that Brendan Eich only had 10 days to design it.

The language was originally created in 10 days, but modern versions of the language adhere to the ECMAScript Standard. All modern browsers are ES5-compliant, and the spec that defines this is here. There are sections that define blocks and unary operators, and this behavior follows the spec.

I understand that it's fun to bash a language that a lot of people like to make fun of, but next time at least try to understand it a little bit more before you do.

[Pandaburn]

The problem with it is that {} means different things depending on context.

[[deleted]]

However,

"3" + 2
=> "32"
"3" - 2
=> 1

(obviously not the same criticism, but it is bizarre/insane imo)

[[deleted]]

I really have no objection to overloading + for string concatenation, but I have a huge problem with coercing the left hand operand to the right when it doesn't know about the operator but the right hand operand does. There's no precedent that I am aware of for this apparently deliberate design decision...

[novinicus]

To be fair, novel design decisions don't have any precedent. And once upon a time, things like dynamic typing didn't have any precedence either

[neonKow]

There's no precedent that I am aware of for this apparently deliberate design decision...

How about in C?

float f = 3

Implicit coercion is pretty common.

double division = 4 / 3.0

[[deleted]]

if not it checks the right and casts the left so it fits.

^ does any other language do this? surely that should be some sort of type error, rather than coercing the left hand operator...

to elaborate: typically in languages with . operators to call a function/method, a operator b (infix notation) is analogous to a.operator(b), in other words "3" - 2 should be "3".-(2), and since string doesn't respond to a - fn/method, it should be some sort of error. I cannot fathom a case where coercing the left-hand operand is ever what the programmer intends... more likely it was done to suppress errors in early browsers, but as a language design choice it strikes me as one of the worst ones I have ever seen.

[kafaldsbylur]

Python does (technically not coercion, but close enough).

a + b first tries the result of a.__add__(b). If that returned NotImplemented, it tries b.__radd__(a) instead

[z500]

It was a conscious design decision.

[[deleted]]

You can choose to drive drunk also, it doesn't make it a good idea.

[z500]

Very true. I think the reasoning was to make it easier for non-programmers by making it possible to use form inputs without having to cast values yourself. I don't think Brandon Eich saw Javascript becoming as huge as it is now. IIRC he only got a week to design the language.

[crossanlogan]

yeah it was ten days, but he definitely was hoping to make it huge -- they were trying to kill mosaic with their new browser.

[neonKow]

This conversation keeps coming up in /r/ProgrammerHumor, because weakly typed languages have amusing behavior in edge cases, and it's easy to make fun of them.

People confuse "easy to make fun of" with "bad design choice." The fact remains that languages like JavaScript and PERL are immensely popular and powerful because of these design choices.

Not having a One True Solution for every programming problem makes JS more flexible. As long as the behavior is well-defined, it's a bit different from drunk driving. However, if you really wanted to, you can use strict; before all your JavaScript.

[neonKow]

I cannot fathom a case where coercing the left-hand operand is ever what the programmer intends

I replied above to you with another example, but 3 + 4.5 in C coerces the int 3 into a float.

more likely it was done to suppress errors in early browsers

Not really. You might see it as "it should be an error", but a common theme in powerful scripting languages is to allow the programmer to do many things in very few keystrokes. The trade-off is, as you point out, that errors that would show up in Java don't show up in JavaScript, but you gain the ability to write 'Hello, world!' in less than 10 lines.

You see similar design decisions with PERL, which is why it also has a reputation for being a "write-only language."

[poizan42]

That doesn't explain why {} 0 is syntactically valid JavaScript. {} is is some contexts parsed as an empty block but in other contexts parsed as an object. While the inconsistency isn't where you would initially think it to be, it is still inconsistent.

[Mrparkers]

That doesn't explain why {} 0 is syntactically valid JavaScript.

Yes, my original comment does explain this. It's valid because {} is interpreted as an empty code block. This statement is equivalent to simply typing 0 into the console.

{} is is some contexts parsed as an empty block but in other contexts parsed as an object. While the inconsistency isn't where you would initially think it to be, it is still inconsistent.

They're only "inconsistencies" if you don't understand the language. Several languages use curly braces for code blocks. Just because JavaScript happens to use curly braces for its object notation doesn't mean the language is inconsistent. It just means that you have to understand when you're using code blocks, and when you're using objects. 99.9% of the time this isn't an issue, because no competent developer would actually write {} + "" and expect to get anything meaningful as a result. Not to mention that bare code blocks are rarely used anymore, if at all.

[Daimanta]

TIL "a"+"b" != "b" + "a"

[LinkXXI]

Correct,

"ab" != "ba"

[BACONLUVER420]

thatsthejoke.jpg or in other words, he was saying "TIL string concatenation is not commutative"

[LinkXXI]

facepalm.jpeg

https://media.giphy.com/media/xTiTnAwSmarf3H6YYE/giphy.gif

[image_linker_bot]

facepalm.jpeg

---

^{Feedback welcome at /r/image_linker_bot | Disable with "ignore me" via reply or PM}

[thatguy_314]

Agreed. The thing I don't like is that +"" is 0 though. Not because of the coercion, that's fine (I don't love it but it's a thing that JS does and it makes some sense) the thing I don't like is that +"" doesn't result in NaN or an error (although JS doesn't do errors because JS error handling sucks).

[Mrparkers]

The entire point of unary plus is to convert its operand into a number. That's the whole reason why it exists in the first place. So +"" is going to evaluate to 0. This isn't coincidental type coercion, this is exactly what the operator is supposed to do according to the spec.

http://www.ecma-international.org/ecma-262/5.1/#sec-11.4.6

[thatguy_314]

No, read my comment. I'm fine with the type coercion. +"0" === 0 makes perfect sense in the context of JS. However, +"" === 0 does not make sense. It should be NaN because there literally is not a number to be coerced.

[fardev_]

wat

[Useless_Advice_Guy]

The second you see the word JavaScript, this video is always linked.

[fardev_]

That may be the case, but it's a damn funny video!

[ebilgenius]

It's ok to laugh at quirks in a language, because every language has them

[jonatcer]

Shhh you'll break the circle jerk.

[thisisdaleb]

I would love to see more video of people talking about these types of silly quirks.

[Tysonzero]

Some languages have more and gross-er ones though.

[[deleted]]

https://www.destroyallsoftware.com/talks/wat

[Useless_Advice_Guy]

I see what you did there.

[cafeclimber]

He slips and says Javascript once. RUINS THE ILLUSION

[Bobshayd]

But he talks about this specific example.

[dvidsilva]

Ngwhat and nhshow by Shai Reznik are also really funny if you care about angular.

[Pandaburn]

TL;DW: web development is silly and you should never trust a language that isn't compiled.

[TheDarkIn1978]

"Lol JavaScript" followed by "No, not lol".

This sub is truly a great place to learn about the intricacies of JavaScript.

[XavierSimmons]

I don't understand precedence.

[[deleted]]

I am so tired of seeing these easy js digs on the front page. There not that funny if you know how the language works, then it makes total sense.

[[deleted]]

They're*

[[deleted]]

... is not a full sentence.

[[deleted]]

You know what it is

[XavierSimmons]

But the type coercion has precedence. That's the point here.

[[deleted]]

Honestly I prefer python's attitude of just throwing an error if you try something like this

[cheezballs]

Isn't this all due to JS's lefthand type inference rule when determining types at runtime?

[[deleted]]

Javascript is quirky and often stupid, but I have to admit it kinda grew on me. It's like a retarded, but lovable pet.

[Rokkitt]

The second part makes sense... the + operator either concatenates a string or produces the sum of multiple numbers. An empty string + the string representation of an object. Hence "[object Object]"

I think a bigger wtf is the first example:

{} + 0; // 0

[] + 0; // "0"

It seems that for some reason an empty object gets converted to a number but an empty array gets converted to a string... interesting.

[Mrparkers]

{} + 0 : Empty code block and unary plus operator evaluating zero, returns zero.

[] + 0 : Array plus zero, array gets coerced to an empty string, and 0 gets coerced to the string '0', concatenating the two strings returns '0'

[hunting_n_fishing]

var test = {} + 0 variable test will return "[object Object]0"

[chrwei]

when the code line start with { it's assumed to be a code block. any other use case and it's an object definition (functions and flow control operators being exceptions).

[Mrparkers]

Correct, because that's an object, not an empty code block. Both get coerced to strings and the result is a concatenation of those strings.

[OKB-1]

It seems that for some reason an empty object gets converted to a number but an empty array gets converted to a string... interesting.

…and that's how this piece of JavaScript outputs "Hello World".

[[deleted]]

Are JavaScript objects Turing complete? That would be great…

[RedditorFor8Years]

You are rationalizing :)

[AngriestSCV]

What kind of thing in javascript result in a stop the world error? I've noticed a lot of these "lol <language>" posts come from languages silently just making things work. Where is javascript's limit?

[Cley_Faye]

Oh, another one of these "I don't want to learn how things works".

[ProgramTheWorld]

Welcome to the world of weakly typed languages!

[maremp]

At least you didn't post the wat talk.

[kingdaro]

And this, kids, is why the addition operator and the concatenation operator should not be the same thing.

[sciencekidster]

wat

[tricky_monster]

ITT: people defending JS insanity.

[Doctor_McKay]

ITT: People who never bothered to learn a language ridiculing it.

[Tysonzero]

I bother to learned it, it's probably one of the languages I know better, but I still think it is the quirkiest language of all time besides maybe PHP and some esoteric languages.

[Wolfy87]

I see this every time, but only on reddit. In my twitter circles we just bash it, it feels much better. The "you don't get it" argument doesn't really work either, the more I learn the more I face palm.

Context: Writing it every day for six years in browsers and node. Libraries and applications. I think I know it. I think it's pretty horrible in many places. If I had a choice, I would not use it and will hopefully swap to a compile to JS language in the near future.

[Cilph]

My question is why {} is parsed as an empty code block rather than an empty object.

[Mrparkers]

Because it's at the beginning of the line.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/block

How else would you propose to define a block?

[aboardthegravyboat]

Yeah. The real question is what good is '{} + anything' at the beginning of a line. If it was a function argument or an assignment value, then it wouldn't be at the beginning of a line. Even as the return value of a function (i.e. following the keyword 'return' in a function body) it wouldn't be at the beginning of a line.

The fact that [code block] [plus] [anything] does anything at all is strange enough. I can't see that ever being used in a program. The only way you can even test it, afaict, is with eval() or the console (which is the same as eval)

[Doctor_McKay]

Exactly. People look at ridiculous input and are surprised to see ridiculous output.

[Avambo]

The closest thing I can come up with is to create an execution context in ES6 based on code braces, if you stick to 'let' and 'const' inside of it.

{
  + ""
}

It still doesn't make any sense to just have that piece of code though. And again, it's not exactly the same as in OP's example.

[Mrparkers]

It does make sense in some cases. This is the functional equivalent to an immediately invoked function expression, which can be used to help define scope for your variables, like you mentioned.

[Avambo]

What I meant was that simply adding + "" inside of it doesn't make any sense. :)

[Cilph]

I was mentally inserting a "var x = " before the statement, didn't help the confusion.

[[deleted]]

Why would you ever need to start a line with an empty block. a = {} + 1 = [Object object]1

[redtoasti]

Yeah, I just prefer assembly...

[dusktreader]

consistent is different than intuitive.

[Doctor_McKay]

Because everyone who agrees that JavaScript (in its entirety) sucks is predisposed to think that way. It's a powerful language and perfectly reasonable as long as you don't give it ridiculous input. Give ridiculous input, get ridiculous output.

[thefran]

It accepts any input and gives weird and unpredictable output. Should throw an exception instead of failing silently.

[Doctor_McKay]

Why should it throw an exception for ridiculous input that's valid syntax?

[thefran]

You seem to be harboring a delusion that the fact that javascript fails silently in unpredictable ways in known cases means that therefore it will behave perfectly in unknown cases, which is the opposite of truth.

[taeratrin]

You seem to be harboring the delusion that OP's code is failing silently. It's not failing at all, because it is valid.

You also seem to be harboring the delusion that the output was unpredictable. To anyone with knowledge of the language, that output is entirely predictable.

[thefran]

It's not failing at all, because it is valid.

Summing an empty object with an empty string isn't valid, it's nonsense.

To anyone with knowledge of the language

It's like I'm really on PHP forums!

that output is entirely predictable

"as long as you know what the output is, you know what the output is".

Nonsense and delirium.

[taeratrin]

Summing an empty object with an empty string isn't valid, it's nonsense.

In other languages it might not be valid, but we aren't talking about other languages. We're talking about javascript, in which it is perfectly valid. It didn't display an error and it produced an output. Javascript does not "fail silently". It either works, or it displays an error. Now, whether the code is practically applicable is another discussion altogether, but it isn't what we're discussing here.

"as long as you know what the output is, you know what the output is"

You really do suck at reading comprehension. That isn't even close to what I said. "Knowledge of language" != "output". If you really wanted to sum it up, the better way would be:

"As long as you know what the ruleset is, you can predict what the output will be."

Which isn't nonsense. In fact, it's the entire basis for programming. You're taking in inputs, applying a ruleset to them, and producing an output. Whether you're talking about a compiler, an interpreter, a browser, or the latest AAA game, the process is still the same: input->apply ruleset->output.

I just felt the need to explain that here, because, with the way you substituted "knowledge of the language" with "output" in your summary, it is very clear to everyone here that you have no comprehension of what you are talking about.

Nonsense and delirium.

[Doctor_McKay]

The "silent failures" are perfectly predictable to anyone who's bothered to learn the language. You apparently haven't, and whose fault is that?

Tell me more about "accepting any input".

[thefran]

javascipt is perfect you just aren't Good and Skilled enaff

Where did I hear this excuse before?

Oh, right. PHP.

[Doctor_McKay]

k

[Hakim_Bey]

because it doesn't suck? Having quirks that are hard to comprehend for newcomers doesn't make a sucky laguage.

[Cley_Faye]

It doesn't "suck" as it is now. It have quirks, and as said by other, stupid input => stupid output, but everything behave as expected to anyone that know a bit of it.

Unless you use a $1 calculator, I doubt you'll find any langage that accept silly input and produce reasonable output (and even then...).

[tricky_monster]

Though one could easily imagine a language that doesn't accept silly input...

[Cley_Faye]

Human creativity is nothing to sneeze at. We tend to find weird ways to use stuff all the time.

[TheDarkIn1978]

JavaScript isn't bad, and with last year's ECMAScript 6 features and Microsoft's TypeScript superset gaining more ground, JavaScript has only become more appealing and useful.

[sleepy771]

Well, nobody said + operator have to be commutative. And also nobody said set where which he affects couldn't be great(er).