• Olap@lemmy.world
    link
    fedilink
    English
    arrow-up
    12
    arrow-down
    3
    ·
    edit-2
    1 year ago

    I keep telling noobs that writing code is like 10% of what they do, and each line of code is a millstone round their neck. Terse, optimal performance (not optimized!) code meeting user requirements is the route to success. And so, doing less is how to go faster, but not what the video means

    • monobot@lemmy.ml
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      Fastest and most maintainable code is one that does not exists.

      Best one after that is it short and simple one.

    • 🇰 🌀 🇱 🇦 🇳 🇦 🇰 ℹ️@yiffit.net
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      1
      ·
      edit-2
      1 year ago

      Now, I am just a modder and not a full blown dev or anything, but I’ve always questioned others who critcized my scripts and suggested much more complicated ways of doing the same thing. Like I can do exactly what I wanted with 1 line of code, and someone would come in and say “do it this way for better results” and it’s 6 lines of crap that ends up working exactly the same. Why?! Especially when this was for a game that has a notoriously slow script engine, meaning more lines of code = slower, no matter what you were doing.

      • Tamo@programming.dev
        link
        fedilink
        English
        arrow-up
        7
        ·
        1 year ago

        Generally the performance difference will be minimal, but the benefit to others (and yourself in the future) in keeping the code’s functionality clear and readable is much more important, especially in a professional setting.

        A lot of programmers do have this ‘code golf’ mentality that less lines == efficient, but unless its a bottleneck and you’ve benchmarked it to be significantly faster, code readability should always trump performance.

        • douglasg14b@programming.dev
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          1 year ago

          Hard agree.

          Less code is not a positive metric to measure your implementation by, and is not a valid premise to justify itself. Often increasing the complexity (again, LOC is not an indicator of complexity), tanking performance, and harming the debugging experience is a common result of the mentality. Things that make software worse.

          Not all one-liners are bad ofc, that’s not the argument I’m making. It’s about the mentality that less code is more good, where poor decisions are made on a flawed premise.

      • douglasg14b@programming.dev
        link
        fedilink
        English
        arrow-up
        5
        ·
        edit-2
        1 year ago

        That single line of code may be using a slow abstraction, doesn’t cover edge cases, has no caching of reused values, has no optimization for the common path, or any other number of issues. Thus being slower, fragile, or sometimes not even solving the problem it’s meant to solve.

        More often than not performance and robustness comes at a significant increase to the amount of code you have to write in high level languages… Performance optimizations especially.

        A high performance parser I was involved in writing was nearly 60x the amount of code (~12k LOC) of the lowest LOC solution you could make (~200LOC), but also several orders of magnitude faster. It also covered more edge cases, and could short circuit to more optimal paths during parsing, increasing the performance for common use cases which had optimized code written just for them.

        More lines of code = slower

        It doesn’t. This is a fundamental misunderstanding of software engineering and is flawed in almost every way. To the point of it being an armchair statement. Often this is even objectively provable…

        • It doesn’t. This is a fundamental misunderstanding of software engineering and is flawed in almost every way. To the point of it being an armchair statement.

          I was talking about a specific edge case there. The way the scripting system for ARMA is handled, a longer script will take more time to parse and run than a script that can do the same thing in fewer lines, except in some rare instances where you actually could optimize how it’s handling a certain function.

      • Olap@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        1 year ago

        Less lines doesn’t automatically mean a CPU does less. I can write a one liner in ruby that will munch through a thread. But in general you’re correct imo

        My comment though was more that performance isn’t about just CPU time. Development time is another performance metric, as is maintenance, overly complicated abstractions can yield big brain points but rarely anything else

        If you solve only the problem you have with less code (why, some sort of example driven development may be of service here) then you’re on the road to better everything

    • douglasg14b@programming.dev
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      2
      ·
      1 year ago

      each line of code is a millisecond round their neck

      My man here thinking performance optimizations= fewer lines of code 😂😂😂

      • Olap@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        1
        ·
        1 year ago

        Let me rephrase then as you missed my point. Each line of code is a millstone around you, your team, and your companies neck. Maintainability usually corellates to LOC. Performance often aligns to LOC. Understanding your Big-O is far easier with less lines for when you do need to optimize. It’s easy to write ten lines of code. The wisdom comes from knowing which of those lines you need and which you don’t