• CanadaPlus@lemmy.sdf.org
    8·
    15 hours 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.

  • garlicandonions@lemmy.world
    4·
    22 hours ago

    It’s documentation. I’m a strickler to type in python so later when I look at my code and go what does this do it’s easier.

  • xthexder@l.sw0.com
    10·
    1 day ago

    For NASA, data types don’t matter when you’re programming Voyager 1 and 45 years later it gets hit by an energy burst causing 3% of the RAM to become unusable, and it’s transmitting gibberish. It’s awesome they were able to recover it.

  • livingcoder@programming.dev
    281·
    2 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.

  • zenforyen@feddit.org
    362·
    2 days ago

    Python with type hints and mypy and ruff = <3

    Large Python codebase without types = nightmare

    • smiletolerantly@awful.systems
      11·
      1 day ago

      I’m too lazy to insert the “look what they need to mimic a fraction of our power” meme here, so… Please imagine it instead.

      I’m switching jobs in a couple of months, and I am SO glad to be leaving a (very well maintained!!) python codebase with type hints and mypy for a rust codebase.

      It is just not the same.

      • zenforyen@feddit.org
        3·
        16 hours ago

        Nice! I’d love to use Rust at work, I was a Haskell guy for hobby things, rather recently switched to Rust for that, and I enjoy it a lot. Taking 80% of the good lessons from functional programming while staying performant and practical and just have nice tooling - whoever designed Rust are wise people who know what is important for happy developers.

        My job is mainly C++, and if you have seen the bright side of life, it is difficult not to be frustrated by the language and tooling. I think C++ without clang-tidy is almost as horrible as Python without types and linters. Undefined behavior and foot guns everywhere!

      • Ethan@programming.devEnglish
        6·
        2 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
              21·
              1 day 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?

              • gedhrel@lemmy.world
                1·
                4 hours ago

                I worked on OpenStack back in the day: millions of lines of untyped Python.

                Let’s say you’ve got an X509 certificate. You know you can probably pull the subject out of it - how? Were I using Java (for instance), the types would guide my IDE and make the whole thing discoverable. The prevalent wisdom at the time was that the repl was your friend. “Simply” instantiate an object in the repl then poke at it a bit.

                And it’s not just that kind of usability barrier. “Where is this used?” is a fantastic IDE tool for rapid code comprehension. It’s essentially impossible to answer for a large Python codebase.

                Don’t get me wrong: python is still a great go-to tool for glue and handy cli tools. For large software projects, the absence of type enforcement is a major impediment to navigation, comprehension and speed of iteration.

                • gedhrel@lemmy.world
                  1·
                  4 hours ago

                  And as for your specific question: typechecked code doesn’t get to production with a type error; it won’t compile. There’s a common phrase, “left-shifting errors”. It means catching bugs as early in the development cycle as possible. In terms of things like developer time (and patience), it’s far more cost-effective to do so.

    • Ethan@programming.devEnglish
      121·
      2 days ago

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

      • h4x0r@lemmy.dbzer0.comEnglish
        5·
        2 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.

        • Trailblazing Braille Taser@lemmy.dbzer0.com
          23·
          1 day 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.