DelfEvery once in a while i start to feel like i want to do FE again... Then something like this happens and i immediately loose all my motivation.
#javascript #frontend
#javascript #frontend
CFDS@leKnecht What would you expect to happen?
@CFDS the result of empty-array + array-with-two-empty-strings should be array-with-two-empty-strings. And not a string with one comma in it with no reason, which is beyond WAT. I got irritated when i saw that empty-array plus empty-array results in empty-string, which is already stupid as hell, but OK, its JS..¯\_(ツ)_/¯
But this? ... I dont know. Its creating commas out of thin air.. thats so stupid.
@leKnecht `+` is not an array concatenation operator in javascript. You could do [].concat(...["", ""]) instead.
When you use `+` with arrays, javascript tries it's best to comply with weird orders, converting both sides of the operand into a string. When arrays are stringified, JS adds a comma in between each item.
The usual rule of garbage-in-garbage-out applies.
When you use `+` with arrays, javascript tries it's best to comply with weird orders, converting both sides of the operand into a string. When arrays are stringified, JS adds a comma in between each item.
The usual rule of garbage-in-garbage-out applies.
@CFDS See, even with an explanation, its still stupid as hell. Its so sad that this crap is still the same since https://www.destroyallsoftware.com/talks/wat
Why cast arrays to strings in the first place 🤷 why not type-error if `+` wants to see stringable things. Why does `+` want to see strings. Number+number is number, not number-as-string for example. Hach.
@leKnecht What's stupid is to expect sensible output from nonsensical input. And while "wat" is a funny speech, the kinds of problems it highlights are practically never an issue in real life projects. It's easy to cherry pick weird features of a language, but do you think such features are stopping (or even slowing) people from getting work done? Not to mention JS is not the only dynamically typed language that does type coercion. See: Python, Ruby, PHP, Perl, Lua...
@CFDS well i hit this in a real-life project :)
There is nothing wrong with admitting that parts of a language suck btw... i did a lot of PHP, i have no problems with admitting that eg haystack-needle positioning inconsistency there is super stupid. Or GC..or speed.. Or Python, where the actual error in error reporting is often somewhere at ~3/4 of the 20-pages-long error message. Or Java where ..its Java. Golang and "exceptions"..
Dont feel attacked :) If you like JS, then thats good :)
@leKnecht IMO it's less about "[dis]liking" JS and more about knowing your chosen tools and using them accordingly. Like, I wouldn't say a hammer sucks because I tried to drive screws with it and the result didn't come out great.
@CFDS i think that this metaphor doesnt fit completely-legit expectations like "order of left and right operant shouldnt matter on + operator"
But its OK if we disagree :)
@leKnecht Except that + isn't just one operation and if you're concatenating strings, then obviously the order matters a lot.
And that's kinda my point. Even if you're used to the plus sign meaning numeric addition in language A, the same assumption might not hold true in language B, where the plus sign is used for concatenation.
In such a case, is the problem in incorrect assumptions, or in language B?
And that's kinda my point. Even if you're used to the plus sign meaning numeric addition in language A, the same assumption might not hold true in language B, where the plus sign is used for concatenation.
In such a case, is the problem in incorrect assumptions, or in language B?
@CFDS unintenional behaviour in languages is not good. If it serves a good purpose, it might be worth it, and then you are right. If not, that behaviour should be fixed, so the language evolves. For example with my local node 16, object+array gives object also if i flip the operants. In my latest-ff console its still "object" and "0" 🤷
So apparently someone of the ES-decision-takers agreed with me and others who thought this is not so good.
So apparently someone of the ES-decision-takers agreed with me and others who thought this is not so good.
@leKnecht Your last example is actually demonstrating a gotcha in REPL/console, and not in JS per se.
"{} + []" can be interpreted as an expression OR as a statement. If it's an expression, the "{}" gets evaluated as an object. If it's a statement, the "{}" gets evaluated as an empty control block.
Different REPLs and consoles use different heuristics for figuring out whether the given line(s) are supposed to be a statement or an expression. This is the cause of seemingly different outcomes.
@CFDS ah! That does make sense. I was already puzzled, as explicit string casts stayed the same on browser and repl.
But i still think that some behaviors do have no benefit / use-case and create pitfalls, so raising errors would be better 🤷
@CFDS in perl (yes, im old) you can have two different variables with same name but different type. 🤷