It makes the code icky and hard to debug, and you can simply return new immutable objects for every state change.

EDIT: why not just create a new object and reassign variable to point to the new object

  • FizzyOrange
    link
    fedilink
    arrow-up
    7
    ·
    22 hours ago

    Yeah the main reason is performance. In some languages if you use a value “linearly” (i.e. there’s only ever one copy) then functional style updates can get transformed to mutable in-place updates under the hood, but usually it’s seen as a performance optimisation, whereas you often want a performance guarantee.

    Koka is kind of an exception, but even there they say:

    Note. FBIP is still active research. In particular we’d like to add ways to add annotations to ensure reuse is taking place.

    From that point of view it’s quite similar to tail recursion. It’s often viewed as an optional optimisation but often you want it to be guaranteed so some languages have a keyword like become to do that.

    Also it’s sometimes easier to write code that uses mutation. It doesn’t always make code icky and hard to debug. I’d say it’s more of a very mild code smell. A code musk, if you like.