• Rizo
    link
    fedilink
    English
    arrow-up
    14
    ·
    3 months ago

    Time coding🤔 runtime: the other way around😜

  • ChowJeeBai@lemmy.world
    link
    fedilink
    arrow-up
    7
    ·
    edit-2
    3 months ago

    …and 5 min in chatgpt. Only you spend 3 days making it work because you never understood coding in the first place.

    • sugar_in_your_tea
      link
      fedilink
      arrow-up
      2
      ·
      3 months ago

      And honestly, even if you do understand coding, you’ll probably spend more time testing the code than it would’ve taken to write and test it yourself.

      We had an applicant use AI in an interview, and they made the same mistake twice in 5 minutes, because that’s the code the model spat out. This was someone with several years of experience (I think they even ran a team for a couple years), so they certainly understood coding, they just trusted their tools too much. We even gave them a softball question, “How confident are you that your code is correct? What would you need to feel more confident?,” and their answer was, “I’m 100% confident that it’s correct” when they should have answered, “I’d need to write some unit tests.”

  • TootSweet@lemmy.world
    link
    fedilink
    English
    arrow-up
    7
    ·
    3 months ago

    “Hardware cycles are cheap. Wetware cycles are expensive.”

    • Paraphrased from something I once heard Jacob Kaplan-Moss say but don’t remember his exact wording at PyCon many moons ago.
    • taladar
      link
      fedilink
      arrow-up
      4
      ·
      3 months ago

      Then why do Python people insist on having the programmer do so much stuff instead of letting a compiler do it?

        • taladar
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          3 months ago

          Verifying that your different pieces of code actually work together. With a static type system and similar compiler features you can lighten the mental load a lot compared to languages like Python where you need to keep it all in your head.

            • taladar
              link
              fedilink
              arrow-up
              1
              ·
              2 months ago

              The problem with optional typing is that it has all the downsides of both but gives you very little of the advantages of a strong static type system, e.g. being able to rely on types catching certain kinds of errors when refactoring because you don’t know for sure that all APIs have types. It is really nothing more than an admission by dynamically typed languages that static types are so useful you can’t really do without them while at the same time not admitting that it might be best to move to a language and library ecosystem that was designed with static types from the start.

  • heavy
    link
    fedilink
    English
    arrow-up
    5
    ·
    3 months ago

    I love C and Assembly as much as the next guy, but implementation time to the optimal solution matters.

  • sugar_in_your_tea
    link
    fedilink
    arrow-up
    1
    arrow-down
    2
    ·
    edit-2
    3 months ago

    Rust:

    2 days, most of it fighting the compiler.

    I did a POC in Rust vs Python. Rust took longer to write, would be harder to maintain by our team, and with numba, the performance difference was small. So we went with Python.

    • taladar
      link
      fedilink
      arrow-up
      2
      ·
      3 months ago

      If you are fighting the compiler you are probably trying to write unidiomatic code (maybe Python-like code?).