This here is my absolute favorits way to diss someone. Send the a wikipeda link and bam!

The native arithmetic operators are prone to floating point rounding errors

The correct way to do it is to load a 500mb library that has an add function in it.

It’s much better to make your own function that uses bitwise operations to do addition.

function add(a, b) {
    while (b !== 0) {
        // Calculate carry
        let carry = a & b;

        // Sum without carry
        a = a ^ b;

        // Shift carry to the left
        b = carry << 1;
    }
    return a;
}

(For certain definitions of better.)

Sure, but at this point it’s your own fault if you don’t use Typescript to keep these issues from happening.

I think it’s less about type system, and more about lack of a separate compilation step.

With a compilation step, you can have error messages that developers see, but users don’t. (Hopefully, these errors enable the developers to reduce the errors that users see, and just generally improve the UX, but that’s NOT guaranteed.)

Without a compilation step, you have to assign some semantics to whatever random source string your interpreter gets. And, while you can certainly make that an error, that would rarely be helpful for the user. JS instead made the choice to, as much as possible, avoid error semantics in favor of silent coercions, conversions, and conflations in order to make every attempt to not “error-out” on the user.

It would be a very painful decade indeed to now change the semantics for some JS source text.

Purescript is a great option. Typescript is okay. You could also introduce a JS-to-JS “compilation” step that DID reject (or at least warn the developer) for source text that “should” be given an error semantic, but I don’t know an “off-the-shelf” approach for that – other than JSLint.

This is fair enough from an idealistic view. In practice, you don’t want your entire website to shit itself because of a potentially insignificant error.

I don’t even know Haskell but it seems like (" ( , ) ") would be an instance of boob.

Oddly enough, in Haskell (as defined by the report), length is monomorphic, so it just doesn’t work on tuples (type error).

Due to the way kinds (types of types) work in Haskell, Foldable instances can only operate over (i.e. length only counts) elements of the last/final type argument. So, for (,) it only counts the second part, which is always there exactly once. If you provided a Foldable for (,) it would also have length of 1.

You can have a dynamic language that is strongly typed to disallow stuff like this. Like Python for example

It’s not nonsensical, implicit type coercion is a feature of JavaScript, it’s perfectly logical and predictable.

JavaScript is a filthy beast, it’s not the right tool for every job, but it’s not nonsensical.

When you follow a string with a +, it concatenates it with the next value (converted to string if needed). This makes sense, and it’s a very standard convention in most languages.

Applying arithmetic to a string would be nonsensical, which they don’t do.

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