Yeah, especially in peace time. When war heats up and resources get scarce, you use the cheapest thing that does the job. But in peace time you feed your military contractors to keep them happy and to keep them researching and developing so you don’t lose out on modern technology development.

(For clarification, with “war time” I mean “being in a war that actually threatens the country”. The US hasn’t been in a war like that for a very long time. They’ve essentially being in “peace time” while having military training and testing facilities in the middle east.

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.

Because there’s in fact no operator overloading happening, true, but that’s mostly an under-the-hood topic.

It should not happen no matter why it does happen under the hood.

Operator overloading for string - string is wrong and type coercion to implicitly cast this to int(string) - int(string) is just as wrong.

This here is apparently the original source of the markdown specification, and there it clearly says that this is the correct behaviour: https://daringfireball.net/projects/markdown/syntax#list

Ordered lists use numbers followed by periods:

1. Bird
2. McHale
3. Parish

It’s important to note that the actual numbers you use to mark the list have no effect on the HTML output Markdown produces. The > HTML Markdown produces from the above list is:

<ol> <li>Bird</li> <li>McHale</li> <li>Parish</li> </ol>

If you instead wrote the list in Markdown like this:

1. Bird
2. McHale
3. Parish

or even:

3. Bird
4. McHale
5. Parish

you’d get the exact same HTML output

Yeah, and almost all languages I know then would throw an exception when you try to use - with a string, and if they offer multiple operators that take a string and a number, they always only perform string operations with that and never cast to a number type to do math operations with it.

(e.g. some languages have + for string concatenation and * to add the same string X time together, so e.g. "ab" * 2 => "abab". It’s a terrible idea to have + perform a string operation and - performs a math operation.)

The NaN isn’t an thrown. It’s just silently put into the result. And in this case it’s completely unintelligible. Why would an operation between two strings result in a number?

"Hello" - "world" is an obvious programmer mistake. The interpreter knows that this is not something anyone will ever do on purpose, so it should not silently handle it.

The main problem here is downward coercion. Coercion should only go towards the more permissive type, never towards the more restrictive type.

Coercing a number to a string makes sense, because each number has a representation as a string, so "hello" + 1 makes intuitive sense.

Coercing a string to a number makes no sense, because not every string has a representation as a number (in fact, most strings don’t). "hello" - 1 makes no sense at all. So converting a string to a number should be done by an explicit cast or a conversion function. Using - with a string should always result in a thrown error/exception.

You aren’t wrong, it wouldn’t be bad for it to just print the help in that case, at least when running interactive.

For automation, printing the full help of a more complex command would completely trash logs.

You mean with an actual plan?

“Agile development” (aka business substituted a plan with utter chaos and daily changing super-urgend demands) has ruined our industry.

Agile done right can be helpful, but in 95% of times, agile isn’t done right.

Electrical engineering can’t quite work like that because if you want to try out a change you have to order new, expensive prototype boards that take time to be finished and delivered. Can’t just run a new pipeline and have the new version in production within minutes.

Does gtfo() then work as expected?

They meant that you’d get the same message no matter what unrecognized option you use. So it’s not like they added a specific check that if you type in -h they will give you the message, but instead you get the same message for any unrecognized option.

The thing in the OP only occurs if you type exit, so they specifically added that message to be shown when the interpreter clearly knows what you want, but you just didn’t say it exactly right.

10 years ago I got into RC planes for a summer, and me and the guy were talking about how ridiculous it is that the milirary is spending so much money on simple drones, when they could just strap some explosives on a cheap hobbyist RC plane/drone for a fraction of the price, and just create swarms of them.

The technology had been widely available for some time already back then. Turns out, it was just lacking a war to do so.

(Just to be clear, we were all anti-war in general, this was just idle speculatiok back then. But if our country was attacked at that time, I’m sure some of us would have ended in a newly created drone force like what happened in the Ukraine.)

http://www.stilldrinking.org/programming-sucks

Especially that + and - act differently. If + does string concattenation, - should also do some string action or throw an error in this situation.

It’s not the client, it’s markup.

Nice, a relevant xkcd that I didn’t guess before clicking the link! Well done!

Have you tried JDownloader?

No you haven’t provided proof. You provided proof that you misunderstood the original post. That’s all. That’s why I call you a broken bot, because you think what you provided was proof and everything I provided was wrong, because you lack the capability of seeing anything but your own delusions.

Your point is that you don’t understand anything that anyone wrote here, that you don’t have the ability to understand what anyone meant by what they are saying and that you believe only your interpretation is the only correct interpretation of the world.

Are you 10 or something?

You took issue with what I said then. And you kept taking issue with it. And now you claim that you don’t take issue with it. So if you don’t just go away.

You might be made of flesh and bones, but your level of understanding is on the level of a very bad chatbot.