"a"+"b" -> "ab"
"a"-"b" -> NaN

With me too, my employer has to start worrying once I put my current position into my linkedin profile.

I agree with your final take, but why would you want to take frontend tickets if you can also do backend work?

Zionism is the one thing where anti-semites and Jews (at least zionist Jews) agree.

Zionist Jews want it because it gives them their own country where they are not persecuted.

Anti-semites want it, because it means that the Jews are not in their country.

That’s why even the literal Nazis supported zionism. Every Jew in Israel was one less Jew in Germany.

You get the same thing still today with the most right-wing politicians supporting Zionism/Israel. On the one hand because it’s a way to keep Jews far away and on the other hand because it can be used as a “I’m supporting Israel, so surely I can’t be a Nazi. Anyway, let’s go shoot some Muslims.”-kind of excuse.

Tbh, immigration isn’t the worst “solution”.

We do have an overpopulation problem. Well, an overconsumption times overpopulation problem, really.

We could fix that by either consuming less (which we apparently, as a species, really don’t want) or by having fewer people (which we apparently really want).

So, in the end, reducing population isn’t a real problem. Even if the population shrinks by 50% each generation (~25 years, for the sake of the argument), there will still be 250mio people left even after 5 generations. The trend should probably be reversed sometime then, but until then it’s really not an issue on the species survival aspect and it would actually be really good for the planet and our long-term survival.

But until then we have mainly one problem: our economic system is based on infinite growth, which can’t work. So again there are two main solutions: either we bring in people from other countries, who benefit from a higher standard of living here while supporting our economic system, or we get rid of the real parasites and freeloaders in our societies: the ultra rich. And again, for some reason we really don’t want to get rid of the rich.

When two men love each other very much, they host a freetube instance where they upload their videos.

As an asexual person, you get just as much sex as most developers get documentation.

Last week I spent a day trying to figure out why the thing in the damn documentation doesn’t work.

Turns out, for that project “latest” doesn’t point to their latest release, but to what they currently have on their dev branch. And apparently they changed the whole module around since the last release.

In a company I used to worked in, they hired a new guy for our team. Contract was signed, he resigned from his last position. New budget comes in a week before he was supposed to start, and his position was cut.

He was basically let go before he started working for us.

Goes to show: in many cases the hireing process is about dumb luck and nothing else. For both sides.

A friend of mine was applying for a job where they required “at least 5 years knowledge with Angular version X.Y.Z” (can’t remember the exact version, but they asked for all three numbers).

He said “I’ve got 7 years of knowledge with version X-2 to X+2”.

The HR person was like “But you don’t have 5 years of knowledge with version X.Y.Z, so you don’t fit for the job”.

The real fun part was that version X.Y.Z had only been out for two years at that time.

Nice!

If JS is chaotic neutral, what then is chaotic evil?

All I’m saying is

"10" + 1 => "101"
"10" - 1 => 9
"a" - "b" => NaN

I recently joined a team that had no backender for a year and the frontenders maintained the backend. In this case the image totally applies.

I once had a company give me an assignment that sounded very much like what you are describing. They said I should allocate 10h at once to implement a real-life task that they had and that their developers “already solved”.

At that point I only wrote a handful messages with their recruiter and hadn’t even spoken to a human there. I didn’t even know anything about the team, my potential boss or the project at that time.

I didn’t even answer back, just ghosted them. I’m not going to spend multiple hundreds of Euros of my time just for some assignent to maybe qualify for an interview.

You always have to balance: Do you want the user to have “some” user experience, or none at all.

In the case of image viewers or browsers or stuff, it’s most often better to show the user something, even if it isn’t perfect, than to show nothing at all. Especially if it’s an user who can’t do anything to fix the broken thing at all.

That said, if the user is a developer who is currently developing the solution, then the parser should be as strict as possible, because the developer can fix stuff before it goes into production.

This is literally the difference between me and my wife ;)

The only difference to the standard that I see is that the standard says it should be 1,2,3,4,5, while at least for me it renders as 5,6,7,8,9.

But that’s probably because it doesn’t render as HTML and thus doesn’t rely on HTML to do the numbering.

You basically defied the whole NaN thing. I may even agree that it should always throw an error instead, but… Found a good explanation by someone:

NaN is the number which results from math operations which make no sense

Well, technically this is the explanation, it really isn’t a good one.

x + 1 with x not being defined also doesn’t result in a NaN but instead it throws a reference error, even though that undefined variable isn’t a number either. And x = 1;x.toUpperCase(); also doesn’t silently do anything, even though in this case it could totally return "1" by coercing x to a string first. Instead it throws a TypeError.

It’s really only around number handling where JS gets so weird.

Yeah but actually there can be many interpretations of what someone would mean by that. Increase the bytecode of the last symbol, or search for “1” and wipe it from string. The important thing is that it’s not obvious what a person who wrote that wants really, without additional input.

That’s exactly the thing. It’s not obvious what the person wants and a NaN is most likely not what the person wants at either. So what’s the point in defaulting to something they certainly didn’t want instead of making it obvious that the input made no sense?

A similarly ambiguous situation would be something like x = 2 y. For someone with a mathematical background this clearly looks like x = 2 * y with an implicit multiplication sign. But it’s not in the JS standard to interpret implicit multiplication signs. If you want multiplication, it needs to explicitly use the sign. And thus JS dutifully throws a Syntax Error instead of just guessing what the programmer maybe wanted.

Anyway, your original suggestion was about discrepancy between + and - functionality. I only pointed out that it’s natural when dealing with various data types.

My main point here was that if you have mathematical symbols for string operations, all of the acceptable operations using mathematical symbols need to be string operations. Like e.g. "ab" * 2 => "abab", which many languages provide. That’s consistent. I didn’t mean that all of these operators need to be implemented, but if they aren’t they should throw an error (I stated that in my original comment).

What’s an issue here is that “1” + 1 does a string concatenation, while “1” - 1 converts to int and does a math operation. That’s inconsistent. Because even you want to use that feature, you will stumble over + not performing a math operation like -.

So it should either be that +/- always to math operations and you have a separate operator (e.g. . or ..) for concatenation, or if you overload + with string operations, all of the operators that don’t throw an exception need to be strictly string-operations-only.

There is operator overloading happening - the + operator has a different meaning depending on the types involved. Your issue however seems to be with the type coercion, not the operator overloading.

For string + string and number + number there is operator overloading, that’s correct. For string + number there is not, there’s only type coercion. It becomes string + string(number). All of that is fine. Other languages do that as well.

What’s not fine is that JS also looks the other way on the type coercion tree: There’s no string - string overloading, so it goes down the type coercion tree, looking for any - operation that it can cast to and it ends up with number(string) - number(string), which makes no sense at all.

If you don’t want it to happen either use a different language, or ensure you don’t run into this case (e.g. by using Typescript). It’s an unfortunate fact that this does happen, and it will never be removed due to backwards compatibility.

It’s not the point of the discussion that there are other languages that are better. This here is about complaining about bad language design, and no matter how you turn this, this is not a matter of taste or anything, this is just bad language design.

You are obviously right that this crap will stay in JS forever. That doesn’t make it good design.