master-wiki/void/Readwise/The Purest Coding Style, Where Bugs Are Near Impossible.md

The Purest Coding Style, Where Bugs Are Near Impossible

Metadata

• Author: Coderized
• Full Title: The Purest Coding Style, Where Bugs Are Near Impossible
• Category: #articles
• Document Tags: dev dev/design-patterns
• URL: https://www.youtube.com/watch?v=HlgG395PQWw
• Archive: https://web-archive.alecodes.page/bookmarks?bf=1&search=&title=The%20Purest%20Coding%20Style%2C%20Where%20Bugs%20Are%20Near%20Impossible

[!tldr] Functional programming is a coding style that emphasizes using functions and avoiding side effects to create more reliable and maintainable code. It promotes concepts like immutability and closures, which help keep data and functions organized. While it can be complex, learning functional programming can enhance your coding skills, regardless of your background.

Highlights

we have imperative, or the paradigm of giving explicit instructions. Basically, the "how." And declarative, or the paradigm of describing our goals. Basically, the "what." View Highlight) dev/design-patterns dev

At the core of the functional paradigm, we have functions, obviously. And these functions need to be usable in a fairly unrestricted way ... we can pass them to other functions and return them from other functions, as well as hold references to them for later use. ... We also need to be able to create closures, which are functions that can access and remember the scope around them.

"A closure is a poor man's object... ...and an object is a poor man's closure." View Highlight)

higher-order functions, which are functions that work with other functions to perform an action. Think filter(), sort(), map(), and so on. These help us create reusable and isolated modules View Highlight)

we have immutability, where we aim to avoid something called side effects. Side effects happen when we allow unpredictable state from outside the scope of a function to affect it in some way, or when we allow a function to make changes outside of its scope. By getting rid of potential side effects, our functions become pure, in that if the same data goes into a function, we can always guarantee the same result coming out, without affecting anything else. View Highlight) c1

Currying brings multiple arguments of a function into their own function calls that we then chain together. It achieves this using the memory scope ability of closures, where each argument stays in memory until the chain completes, and we get our result. In a similar way, we can use closures to create something resembling an object. The first function in the chain acts as a kind of object constructor, and is where we define most of our internal data. View Highlight)

Currying brings multiple arguments of a function into their own function calls that we then chain together. It achieves this using the memory scope ability of closures, where each argument stays in memory until the chain completes, and we get our result. In a similar way, we can use closures to create something resembling an object. The first function in the chain acts as a kind of object constructor, and is where we define most of our internal data. View Highlight)

Currying brings multiple arguments of a function into their own function calls that we then chain together. It achieves this using the memory scope ability of closures, where each argument stays in memory until the chain completes, and we get our result. View Highlight)

we can use closures to create something resembling an object. The first function in the chain acts as a kind of object constructor, and is where we define most of our internal data. This data is privately scoped to the constructor function and is therefore encapsulated by it. We can then return a closure to provide external access to this private data. ... we can go as far as returning multiple named closures to access and manipulate the internal data in more complex ways, further solidifying its object-like behaviors.

In the purely functional paradigm, we work primarily with types and expressions, where the following rules apply: Code is generally evaluated rather than executed, which gives us some interesting new optimization capabilities, such as lazy evaluation and automatic parallelization. Immutability is enforced everywhere, meaning that when we want to make changes to our data, We do so by computing a new constant based on an existing constant. And to keep functions pure, the mere thought of a side effect is punishable by the most horrific torture imaginable. Having to learn... MONADS! View Highlight)

The immutability of the functional paradigm forces us to think more strictly about how we pass data around, helping to ensure that changes don’t happen unexpectedly. View Highlight)

guides us in forming readable code that is highly modular and therefore maintainable. View Highlight)

It does come at the cost of potentially being a bit harder to optimize View Highlight)