• 9point6@lemmy.world
    link
    fedilink
    arrow-up
    53
    arrow-down
    11
    ·
    7 months ago

    Const everything by default

    If you need to mutate it, you don’t, you need to refactor.

    • noli@programming.dev
      link
      fedilink
      arrow-up
      46
      arrow-down
      1
      ·
      7 months ago

      Dogmatic statements like this lead to bad, messy code. I’m a firm believer that you should use whatever style fits the problem most.

      Although I agree most code would be better if people followed this dogma, sometimes mutability is just more clean/idiomatic/efficient/…

      • 9point6@lemmy.world
        link
        fedilink
        arrow-up
        3
        arrow-down
        2
        ·
        7 months ago

        I agree somewhat, but I’d also say any codebase needs some level of “dogmatic” standard (ideally enforced via tooling). Otherwise you still end up with bad, messy code (I’d even say messier, as you don’t even get consistency)

      • Corbin@programming.dev
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        6
        ·
        7 months ago

        Define your terms before relying on platitudes. Mutability isn’t cleaner if we want composition, particularly in the face of concurrency. Being idiomatic isn’t good or bad, but patterned; not all patterns are universally desirable. The only one which stands up to scrutiny is efficiency, which leads to the cult of performance-at-all-costs if one is not thoughtful.

    • lad@programming.dev
      link
      fedilink
      arrow-up
      13
      ·
      7 months ago

      I’d agree with the first half, but not the second. Sometimes mutability allows for more concise code, although in most cases it’s better to not mutate at all

      • 9point6@lemmy.world
        link
        fedilink
        arrow-up
        5
        arrow-down
        1
        ·
        7 months ago

        I feel like I should maybe have put a “probably” in there

        After all “there’s no silver bullet”, but in anything but a few edge cases, the rule applies, IMO

      • 9point6@lemmy.world
        link
        fedilink
        arrow-up
        10
        arrow-down
        6
        ·
        7 months ago

        The app working isn’t good enough, it needs to be maintainable. From a professional perspective, unmaintainable code is useless code.

        Code that mutates everywhere is generally harder to reason about and therefore harder to maintain, so just don’t do it (unless there’s literally no other practical way, but genuinely these are very rare cases)

        • ByGourou@sh.itjust.works
          link
          fedilink
          arrow-up
          1
          ·
          7 months ago

          I personally disagree, forcing yourself to use non mutable variables only leads to longer and more convoluted code.

          • 9point6@lemmy.world
            link
            fedilink
            arrow-up
            2
            ·
            7 months ago

            Fair play, I guess we’re probably just gonna disagree.

            In my experience I’d say mutable code (larger than anything other than toy examples) always results in more time spent fixing bugs down the line, predominantly because it’s objectively harder for humans to reason about multiple one to many relationships rather than multiple one to one relationships. I’d say because you need to think about all possible states of the set of mutable variables in your code in order to completely understand it (and I don’t just mean understanding the intended purpose of the code, I mean understanding everything that code is capable of doing), that usually results in a more convoluted implementation than the pretty linear way you typically read functional code.

            Longer code is practically always better if it’s easier to understand than the shorter alternative. Software engineers aren’t employed to play code golf, they’re employed to write maintainable software. Though I’ll say ultra high performance applications might be the exception here—but 99% of engineers aren’t doing anything like that.

            I’m always happy to be convinced otherwise, but I’ve never seen a convincing argument

    • RageAgainstTheRich@lemmy.world
      link
      fedilink
      arrow-up
      4
      arrow-down
      1
      ·
      edit-2
      7 months ago

      That is a… strange take.

      Random example, imagine a variable that holds the time of the last time the user moved the mouse. Or in a game holding the current selected target of the player. Or the players gold amount. Or its level. Or health. Or current position.

      • frezik@midwest.social
        link
        fedilink
        arrow-up
        4
        arrow-down
        3
        ·
        7 months ago

        In all those cases, the answer is to swap in a new variable and throw the old one away.

          • frezik@midwest.social
            link
            fedilink
            arrow-up
            5
            ·
            7 months ago

            It’s only a const within a function. You can pass the value to another function and changing it as it’s passed. For example:

            const int foo = 1
            other_func( foo + 1)
            

            In functional programming, you tend to keep track of state on the stack like this.

              • frezik@midwest.social
                link
                fedilink
                arrow-up
                7
                ·
                7 months ago

                Keeping state managed. The data for the function will be very predictable. This is especially important when it comes to multithreading. You can’t have a race condition where two things update the same data when they never update it that way at all.

      • whotookkarl@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        7 months ago

        I think the general idea would be to take the original const, and create a new const with the new location applied. Destroy the original when it’s no longer needed or scoped. State maintained through parameters passed to the move function e.g. move(original const, new location) -> new const object instead of stateful members in the object like move(mutable, new location) -> updated mutable.

  • Omega_Haxors@lemmy.ml
    link
    fedilink
    English
    arrow-up
    14
    ·
    edit-2
    7 months ago

    Why even use variables in the first place? Just place the values directly into your code. If you need to change a value, that’s just bad planning. Hell, why even use values either? Just run a loop on the INC instruction until you get the value you need. It’s just efficient programming.

    • noli@programming.dev
      link
      fedilink
      arrow-up
      32
      ·
      7 months ago

      In functional programming, everything is seen as a mathematical function, which means for a given input there is a given output and there can be no side effects. Changing a variable’s value is considered a side effect and is thus not possible in pure functional programming. To work around this, you typically see a lot of recursive and higher order functions.

      Declaring all values as const values is something you would do if you’re a diehard functional programmer, as you won’t mutate any values anyway.

        • noli@programming.dev
          link
          fedilink
          arrow-up
          10
          ·
          7 months ago

          Depends on how deep down the rabbit hole you want to go :p

          • creating a new variable that contains the updated value
          • recursion (e.g. it’s not possible to make a loop that increments i by 1, but it is possible to turn that loop into a function which calls itself with i+1 as argument)
          • avoiding typical types of operations that would update variable values. For example instead of a for loop that updates every element of a list, a functional programmer will use the map function, which takes a list and a function to apply to each element of that list to create an updated list. There’s several more of these very typical functions that are very powerful once you get used to using them.
          • monads (I’m not even gonna try to explain them as I hardly grasp them myself)
  • lemmesay@discuss.tchncs.de
    link
    fedilink
    arrow-up
    9
    ·
    7 months ago

    I oscillate between using more functional paradigms and more object-oriented ones. is that normal?
    I use a linter BTW(TypeScript) if that is a useful info.

    • jkrtn@lemmy.ml
      link
      fedilink
      arrow-up
      9
      ·
      7 months ago

      I think using both is normal. Closures and objects are duals of each other. Do whatever is understandable and maintainable, neither paradigm is magic.

    • ZILtoid1991@lemmy.worldOP
      link
      fedilink
      arrow-up
      3
      ·
      7 months ago

      I also do that. Very simple stuff, especially of those that are easy to optimize for the compiler, are often very close to functional programming paradigms.

    • DickFiasco@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      7 months ago

      I use a combination of both. Objects are declared const, all members are set in the constructor, all methods are const. It doesn’t really work for some types of programs (e.g. GUIs) but for stuff like number crunching it’s great.

      • lemmesay@discuss.tchncs.de
        link
        fedilink
        arrow-up
        2
        ·
        7 months ago

        I heavily use classes while working on back end, and when I’m making a really self-contained logic, such as a logger or an image manipulation service.
        but since most frontend stuff heavily leans on functional side, I go with it