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.

90% of the things that Japan introduced according to comment sections on the internet never happened (or never made it past the prototype stage) and the rest was actually introduced in Korea, not in Japan.

The Japanophilia is strong with a lot of people on the internet.

There’s this idea I’ve been considering for a long time.

Imagine putting a remote controlled firework smoke bomb under the tailpipe, hidden from sight. At best a really stinky one that smells like burned rubber or something.

When someone follows to closely, just fake an engine issue or something by activating the smoke bomb and fill their AC air intake with the smell of burned rubber for weeks. Just to teach them to not follow too closely again.

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.

Well, you said you only have experience from the outside.

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.

Again, support is not development. Experiences with support does not allow conclusions on development.

And having no experience in development doesn’t qualify you to make statements about development.

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 can not change history for any published changes - like I said, doing so makes your repository incompatible with any other clone.

That’s the same on Git.

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.

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

And what’s TCP/IP?

Looks like Mercurial can change the history just fine using the hg command. You just need to enable it first.

https://book.mercurial-scm.org/read/changing-history.html

Git can also be configured to disable history rewrites.

https://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite

So the difference between git and hg really just comes down to the defaults.

I got weirdly invested in this, and by the end I was kinda happy that it was “just” a bug in the tooling and not anything actually malicious.

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