Comment on [deleted]

demesisx@infosec.pub ⁨1⁩ ⁨year⁩ ago

• Lmaydev@programming.dev ⁨1⁩ ⁨year⁩ ago

  Can you explain that opinion a bit?

  source

  • demesisx@infosec.pub ⁨1⁩ ⁨year⁩ ago

    I could go on for a week but here’s some copypasta that mirrors why I wrote this (sorry not to write an essay in my own words). Honestly, there’s a lot more than listed here (like the inherent ability to parallelize any functional code basically out of the box) but let us take a stab at comparing them:

    The functional programming paradigm was explicitly created to support a pure functional approach to problem solving. Functional programming is a form of declarative programming. In contrast, most mainstream languages, including object-oriented programming (OOP) languages such as C#, Visual Basic, C++, and Java, were designed to primarily support imperative (procedural) programming. With an imperative approach, a developer writes code that specifies the steps that the computer must take to accomplish the goal. This is sometimes referred to as algorithmic programming. In contrast, a functional approach involves composing the problem as a set of functions to be executed. You define carefully the input to each function, and what each function returns.

    Advantages of pure functions

    The primary reason to implement functional transformations as pure functions is that pure functions are composable: that is, self-contained and stateless. These characteristics bring a number of benefits, including the following:

    • Increased readability and maintainability. This is because each function is designed to accomplish a specific task given its arguments. The function doesn’t rely on any external state.

    • Easier reiterative development. Because the code is easier to refactor, changes to design are often easier to implement. For example, suppose you write a complicated transformation, and then realize that some code is repeated several times in the transformation. If you refactor through a pure method, you can call your pure method at will without worrying about side effects.

    • Easier testing and debugging. Because pure functions can more easily be tested in isolation, you can write test code that calls the pure function with typical values, valid edge cases, and invalid edge cases.

    source

    • Lmaydev@programming.dev ⁨1⁩ ⁨year⁩ ago

      What stops you writing pure functions in OO? And where does your state go?

      source

      • demesisx@infosec.pub ⁨1⁩ ⁨year⁩ ago

        I edited my comment to talk about imperative vs FP rather than OO vs FP because FP can actually be OO. What I meant was imperative.

        Anyway, in most functional implementations, state is usually handled by a minimal top layer. Functional paradigms are helpful in keeping the complexity to a minimum.

        I like to use the functional core, imperative wrapper design style.

        source

        • -> View More Comments
      • Pipoca@lemmy.world ⁨1⁩ ⁨year⁩ ago

        And where does your state go? How would a list of products be represented in FP?

        The essence of FP is functions working on immutable data.

        In FP, you have an immutable list of immutable products. This is basically the same as how when processing strings, you typically have an immutable array of immutable characters. If you concatenate two strings, you get a new immutable string. If you edit a string, you just get a new string. You don’t just edit the array itself directly.

        Because everything is immutable, though, you can be smarter about updates. All copies can be shallow. Adding something to the front of a linked list is just a matter of making a new node that points to the old list. Arrays are harder, but you can use some clever tree-based structures like a Hash Array Mapped Trie to get fast updates.

        So your state goes into the arguments of your functions.

        source