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

Yup. It’s completely inconsistent in its interpretation of the + operator.

Yeah, this looks dumb on the surface, but you’ve got bigger problems if you’re trying to do math with strings

It’s just doing a lot of stuff for you that it shouldn’t be in first place 🤭

Kinda like log4j!

This has got to be baNaNa

🫣

It is ‘comprehensible’ in the sense that it’s possible to figure out how it happened, but it absolutely does not “make sense” in terms of being a reasonable language design decision. It’s 100% incompetence on the part of the person who created Javascript.

It’s an issue with most if not all languages that aren’t strongly typed.

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

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.

It was never intended to run full applications but only the small business scripts and hobbyist homepage stuff that were the thing in the 90s, across inconsistent browsers that were a jungle of hit and miss behaviour where it was preferred that menus keep working even if the mouse effect was not. Anything of scale was expected to be done in Java. Dynamic web pages did not exist and as anything not static was generated server side into a static html file to be rendered on the client.

Anyway, back then it wasn’t considered the job of the programming language to hold the hand of the aspiring developer as it is common today. It’s not a bad thing that IDE and even compilers and preprocessors try to help you write better code today, but then it simply didn’t exist.

JavaScript is from a different time and because it has the hard requirement or backwards compatibility there is no changing it and has not been for thirty years except to add stuff to it.

I think it’s just silly to ask the past to keep up with the present. Bad code is not the fault of the language regardless, even though junior devs and even seasoned ones like to think so to protect their ego. I think it is better to accept it, learn from it and roll with it because every single platform and language has their weird quirks anyway.

Signed, old dude that learned programming in 8 bit BASIC and 6502 machine code without an assembler, where code bad enough would freeze your machine that required a cold boot and starting over from your last save that you didn’t do.

Now that you mention it, it is a bit funny how Lemmy is hating LLMs as a code generation tool while also hating on the interpreter for their own hand typed code not running.

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.)

The native arithmetic operators are prone to floating point rounding errors

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.

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