In node, I get the same result in both cases.
"[object Object]"
It’s calling the
toString()
method on both of them, which in the array case is the same as calling.join(",")
on the array. For an empty array, that results in an empty string added to"[object Object]"
at either end in the respective case in the picture.Not sure how we’d get 0 though. Anybody know an implementation that does that? Browsers do that maybe? Which way is spec compliant?
Number([])
is 0, and I think maybe it’s in the spec that the algorithm for type coercion includes an initial attempt to convert to Number before falling back totoString()
? I dunno, this is all off the top of my head.The inspector REPL evaluates as a statement-with-value (like
eval
), so the{}
at the beginning is considered an empty block, not an object. This leaves+[]
, which is 0. I don’t know what would make Node differ, however.Edit: Tested it myself. It seems Node prefers evaluating this as an expression when it can, but explicitly using
eval
gives the inspector behavior:So there’s yet another level of quirkery to this bullshit then, it seems. 😆 Nice digging! 🤝
I also noticed that if you surround the curlies with parentheses, you get the same again:
> eval('{} + []') 0 > eval('({}) + []') '[object Object]'
Yep, parentheses force
{}
to be interpreted as an expression rather than a block — same reason why IIFEs have!function
instead of justfunction
./me goes back to get second folding chair.
I thought IIFE’s usually looked like
(function (...params) {})(...args)
. That’s not the latest way? To be honest I never used them much, at least not after arrow functions arrived.
This is why I try my damnedest not to write in weakly typed languages.
string
+object
makes no logical sense, but the language will be like “'no biggie, you probably meant string + string so let’s convert the object to string”! And so all hell breaks loose when the language’s assumption is wrong.You don’t necessarily need types for that kind of thing though, a strict linter that flags that code works just as well
Some automatic conversion is fine.
a=3+0.2
print(“Hello {name}. You are {age} years old”)
That kind of thing. But the principle of least surprise definitely applies. If you get to the point where you’re adding two booleans and a string, I feel like the language should at least say something. At least until the technology exists for it to physically reach out of your screen and slap you.
I love inside jokes. I hope you be apart of one someday
Removed by mod
I’m in this no-experience-to-apprenticeship program and everyone in my class thinks type coercion is the greatest thing ever.
Mandatory link
GIGO
I’ve read different defenses for JavaScript for cases like this, which usually runs somewhere from you shouldn’t be doing that anyway all the way up to if you just understood the language better you’d know why. While I agree with both of those points strongly as general principles, JavaScript also violates the principle of least surprise enough to make it concerning.
For what it’s worth, I do like JavaScript. I really don’t think that there is any perfect programming language.
I really don’t think that there is any perfect programming language.
You’d be wrong 🦀🦀🦀🦀🦀
Compile times say otherwise
That’s a weird emoji to use for elixir
Elixir? Is that the weird older cousin of Gleam?
Fair, I haven’t used Rust so I don’t really have an opinion on it.
JavaScript, like some other languages of the time, was designed with the Robustness Principle in mind. Arguably the wrong end of the Robustness Principle, but still.
That is, it was designed to accept anything that wasn’t a syntax error (if not a few other things besides) and not generate run-time errors unless absolutely necessary. The thinking was that the last thing the user of something written in JavaScript wants is for their browser to crash or lock up because something divided by zero or couldn’t find an object property.
Also it was originally written in about five minutes by one guy who hadn’t had enough sleep. (I may have misremembered this part, but I get the feeling I’m not too far off.)
It was 10 days, but, yeah, not a lot of time, especially for one guy. (That one guy was Brendan Eich, by the way.)
Who would use that kind of type coercion? Who? I want to see his face.
It’s not even the coercion that is the problem here. The types are already bad by themselves.
I take this as less of a “I can’t use this intuitive feature reliably” thing and more of a “the truth table will bite you in the ass when you least expect it and/or make a mistake” thing.
Just use a formatter. It’ll show you that the second one is two statements:
{}
(the empty block)+[]
coerce an empty array to a number:new Number(new Array())
I totally get that: use the right tools and you’ll be okay. This applies to many technologies in this space.
With respect, I still take this advice like hearing “look out for rattlesnakes if you’re hiking there.” It might be safer to just hike where there are no rattlesnakes, instead.
You’re right, of you have compete freedom, do that. If the place you want or need to go to is most comfortably reachable via rattlesnake road, bring boots.
In other words, if you don’t think the wasm landscape is mature enough to build a web thing with it, you are stuck with JavaScript, but you don’t have to rawdog it. I haven’t run in a single weird thing like this in years of writing typescript with the help of its type system, ESLint and a formatter.
Just wait until OP learns about cross product of matrices.
mfw non-commutativeness
It’s best not to touch anything web related, lest you want to go mad. It’s like the elder scrolls or laying eyes on some cosmic horror creature. Tbf this also goes for C++
At least C++ build tools are easier than modern JS.
I don’t think “easier” is the right way to compare here. The C++ build tools will absolutely rewrite your code into something you can’t expect to guess, but it doesn’t make them hard to “use”.
Keep to sane environments to keep sane.
On the other hand, I don’t think you should add those ever
Sure. But in a sane language doing something totally nonsensical like that is an error, and in a statically typed language it’s a compiler error. It doesn’t just silently do weird shit.
Agreed! Unfortunately these maddening behaviors were kind of set in stone several decades ago, and it has been (correctly) decided “Don’t break the web”, these weird quirks are kept in modern interpreters/compilers.
It’s actually quite interesting to read through the logic to follow when implementing an interpreter:
https://262.ecma-international.org/13.0/#sec-object.prototype.tostring
a sane language
JavaScript
Pick one.
I thought it was clear I was saying JavaScript is not a sane language for this very reason
What’s a sane, dynamically typed language?
I was trying to make a point without starting a flamewar that was beside the point. Personally I’d never choose a dynamically typed language for a production system. That being said, Python and Ruby complain if you try to add an array, dict/hashmap, string, or number to another (of a different type) so they’re certainly more sane than JavaScript.
Lisp?
Onfuscators probably use it though, so no spec ever will be able to get rid of this crap.
Can I vote for obsfuscators not holding a language hostage?
Best I can do is tie your pension to it.
Only if I can vote for sandwiches not falling apart when I eat them
I come back to watch this every few years. It’s so good!
I’ve seen this guy referenced twice today. If only he knew how to write instead of giving talks…
How do I know so little about programming yet this is still so funny?
Maybe the neuroscientists have some insight:
You can tell that they find the answers absurd and the WAT memes are universally funny.
{} + 0 >> 0 0 + {} >> "0[object Object]"
I’m going home.
0 == [] >> true "0" == [] >> false 0 == "0" >> true
Take an empty list and add an object to it. Get a list with an object in it.
Take an object and add an empty list to it, that doesn’t do anything, get a zero for false?