• AbsolutelyNotCats
    link
    fedilink
    English
    49
    edit-2
    1 year ago

    Just a reminder that JavaScript was developed in 10 days, the same amount of time i spend fixing bugs when i just miss a “,”

  • @nxfsi
    link
    471 year ago

    The tech equivalent of inventing leaded gasoline.

    • Rikudou_Sage
      link
      fedilink
      311 year ago

      Has anyone actually read through that? Reading the first few examples and it’s just not understanding how languages work half of the time:

      !!"false" == !!"true"; // -> true
      !!"false" === !!"true"; // -> true
      

      Wow, no shit, non-empty string coerces to true, who would’ve guessed! Did you know that !!"bullshit" === !!"true" as well? Mind=blown.

      NaN === NaN; // -> false
      

      Again, no shit, that’s in the NaN specification and the page even mentions it, so why even include it?

      • @[email protected]
        link
        fedilink
        231 year ago

        Which is why I’m of the opinion that dynamically typed languages are evil. !!“false” should either be caught at compile time or raise an exception.

        I’m thoroughly convinced that the only use of dynamically typed languages is to introduce bugs

        • @[email protected]
          link
          fedilink
          81 year ago

          I am with you. To me these are non-obvious details, just a bug waiting to silently happen in production.

        • @marcos
          link
          41 year ago

          Dynamically typed doesn’t imply it’s monotyped. And monotyped languages can work just fine, you just have to not hide different operations under the same symbols just differing by type like JS does.

          The entire problem with JS is that it both is monotyped and it isn’t.

          • @Pipoca
            link
            11 year ago

            Isn’t the whole point of dynamic languages that they’re monotyped? They’re equivalent to a type system with only one type, any. Really, most dynamic languages are equivalent to having a single tagged union of all the different sorts of values in the language.

            If you add additional types, you get into gradual type systems.

            • @marcos
              link
              11 year ago

              A language has dynamic types if the type-resolution is done at runtime. The other kind is static types, where it’s done at compile-time.

              A language is monotyped if every value is compatible with every operation, so there’s actually no type resolution.

              A language has explicit types if you declare your types, implicit ones if you can’t declare them, type derivation if declarations are optional but they exist and are static you declaring or not, or gradual types if declarations are optional but they exist and are dynamic you declaring them or not.

              All of those things are different.

              Also, some people will insist “types” can only be static. Go ask those people whatever is the name of the things Python have, because either they just invented some different words, or they are only trying to confuse you.

              • @Pipoca
                link
                11 year ago

                Bob Harper uses ‘unityped’ in his post about how dynamic typing is a static type system with a single type in disguise. I’ve literally never heard “monotyped” used as a term in a dynamic context.

                In Types and Programming Languages, Ben Pierce says “Terms like ‘dynamically typed’ are arguably misnomers and should probably be replaced by ‘dynamically checked’, but the usage is standard”. Generally, you’ll see ‘tag’ used by type theorists to distinguish what dynamic languages are doing from what a static language considers a type.

                Type systems have existed as a field in math for over a century and predate programming languages by decades. They do a slightly different sort of thing vs dynamic checking, and many type system features like generics or algebraic data types make sense in a static context but not in a dynamic one.

                • @marcos
                  link
                  1
                  edit-2
                  1 year ago

                  many type system features like generics or algebraic data types make sense in a static context but not in a dynamic one

                  Hum… Not so much. You can do polymorphism with dynamic types perfectly well, with mechanisms that are exactly equivalent to the ones used on static languages (python people just love that). You can also have tagged unions with a completely equivalent mechanism from algebraic data types (that everybody ends-up doing in json sooner or later). Also you can do out of order verifications in a logical fashion, rewrite code at run time, or anything else even. It’s compile-time that has limitations on what it can do, runtime has none.

                  I am not at all against inventing new names. But I am really against naming concepts that are not independent from each other. And insisting on those is just signaling-oriented pedantry. So you can very well insist that the dynamic thing is not called “type”, but you can’t really do it in a way that implies the only thing you can get out of them is a type mismatch error.

        • Rikudou_Sage
          link
          fedilink
          English
          11 year ago

          Why? IMO that’s perfectly valid. The various type coercions are sometimes crazy, but IMO the rule that non-empty string is coerced to true and empty string to false is very simple to follow. The snippet is not even a gotcha, I don’t see anything worth failing over. Putting “true” or “false” in a string doesn’t change that.

          • @[email protected]
            link
            fedilink
            5
            edit-2
            1 year ago

            I am dumb. The more things I need to think about when reading code that is not the logic of the code, the worse it is. Any time I have to spend thinking about the peculiarities of the way the language handles something is time wasted.

            I’ll give a very simple example, think like you’re trying to find a bug. Assume we’re in a dynamic language that allows implicit conversion like this. We can write our code very “cleanly” as follows:

            if(!someVar) doSomething();

            -> ok, now we gotta check where someVar’s value is last set to know what type of data this is. Then I need to remember or look up how those specific types are coerced into a bool.

            When trying the same code in a statically typed language that doesn’t do implicit coercion that code will fail to run/compile so probably you’ll have something like this:

            if(someVar.length() == 0) doSomething();

            -> this time I can just look at the type of someVar to see it’s a string and it’s clear what the condition actually means.

            The second option is both easier to read and less bug prone even without the type system. It takes maybe 3 seconds longer to type, but if your productivity in coding is that limited by typing speed then I envy you

      • darcy
        link
        fedilink
        41 year ago

        NaN===NaN is the fault of the floating point standard tho i believe.

      • @[email protected]
        link
        fedilink
        11 year ago

        Also, a huge proportion of the list is just not understanding IEEE floats behaviour and blaming the language for it. Exactly like this post is doing. All those weird number things js does is because it only uses floats for everything and every language that uses floats will behave the exact same way.

    • @[email protected]
      link
      fedilink
      11 year ago

      So, uh, first example, the developer decided instead of comparing based on type, he rather converts the values? Why?!

    • @FehrIsFair
      link
      161 year ago

      This image is fan art of Gawr Gura from Hololive EN’s 1st Gen VTuber group HoloMyth.

      She is their most subscribed talent and is known for being computationally challenged.

  • tun
    link
    fedilink
    11 year ago

    Approach the problem from different angle!