• CanadaPlus@lemmy.sdf.org
    4·
    6 days ago

    Eh, strict typing makes debugging way, way easier. Saint Grace brought us compilers for a reason. If all you have is assembly, you should start writing one.

      • Ethan@programming.devEnglish
        4·
        7 days ago

        “Assume it’s a map and treat like a map and then catch the type error if it’s not.” Paraphrased from actual advice by Guido on how you should write Python. Python isn’t a bad language but the philosophy that comes along with it is so fucked.

            • manicdave@feddit.uk
              1·
              6 days ago

              Why though? I’ve genuinely never had a problem with it. If something is wrong, it was always going to be wrong. Why is it preferable to have to write a bunch of bolierplate than just deal with the stacktrace when you do encounter a type error?

              • Ethan@programming.devEnglish
                1·
                4 days ago

                I’ve genuinely never had a problem with it. If something is wrong, it was always going to be wrong.

                Have you worked on a production code base with more than a few thousands of lines of code? A bug is always going to be a bug, but 99% of the time it’s far harder to answer “how is this bug triggered” than it is to actually fix the bug. How the bug is triggered is extremely important.

                Why is it preferable to have to write a bunch of bolierplate than just deal with the stacktrace when you do encounter a type error?

                If you don’t validate types you can easily run into a situation where you write a value to a variable with the wrong type, and then some later event retrieves that value and tries to act on it and throws an exception. Now you have a stack trace for the event handler, but the actual bug is in the code that set the variable and thus is not in your stack trace. Maybe the stack trace is enough that you can figure out which variable caused the problem, and maybe it’s obvious where that variable was set, but that can become very difficult very fast in a moderately complex application. Obviously you should write tests, but tests will never catch every weird thing a program might do especially when a human is involved. When you’re working on a moderately large and complex project that needs to have any degree of reliability, catching errors as early as possible is always better.

  • livingcoder@programming.dev
    121·
    7 days ago

    When I learned Python I thought that not having a statically typed language was the way to go, but then it just became an issue when I was trying to ensure that everything was at least something like what I was expecting. Going back to statically typed languages even harder with Rust has been a dream. I love it.

    • Ethan@programming.devEnglish
      91·
      7 days ago

      Assembly languages are always architecture specific. Thats kind of their defining feature. Assembly is readable machine code.

      • h4x0r@lemmy.dbzer0.comEnglish
        4·
        7 days ago

        nasm is an assembler though, not a ‘languages’, that only supports x86/x64. gas for example supports a wide range of architectures so you can write risc-v, arm, x64, etc.

        • Ethan@programming.devEnglish
          11·
          4 days ago

          nasm is an assembler though, not a ‘languages’

          That’s like saying “clang is a compiler though, not a language”. It’s correct but completely beside the point. Unless you’re writing a compiler, “cross platform assembler” is kind of an insane thing to ask for. If want to learn low level programming, pick a platform. If you are trying to write a cross-platform program in assembly, WHY!? Unless you’re writing a compiler. But even then, in this day and age using a cross-platform assembler is still kind of an insane way to approach that problem; take a lesson from decades of progress and do what LLVM did: use an intermediate representation.

        • Trailblazing Braille Taser@lemmy.dbzer0.com
          11·
          7 days ago

          Are you arguing that assembly languages are not architecture-specific? I don’t think that’s the typical definition.

          Nasm is an assembler, but it also represents a specific assembly language targeting x86 architectures.

          Gas is an assembler of a higher order. It can emit code for many architectures, and thus it accepts many different architecture-specific assembly languages.