
Demystifying functional programming for JavaScript developers every day. With practical tips that you can start using today even if your team is not practicing functional programming.

<H2>
Introduction
</H2>

If we start with the question, what is a paradigm? To me, a paradigm is a way of doing things; it defines how we think about problems and how we approach them.

Naturally, for us, it is procedural since it feels most familiar, as it is concrete and imperative. We reason about programs like a recipe for a cake; we write concrete and super-specific steps to bake a cake.
While functional is a bit different and needs us to change this habit of thinking in imperative steps, but rather we need to reason about steps in a declarative way. So functional programming is about... you would be surprised by making software with functions 😂. Fundamentally, writing software by composing pure functions and describing functions in a declarative way.

The phrase "declarative programming" means that the program logic is expressed without explicitly describing the flow control.

In the first part of this series, I will focus on functions the most.
<H2>
Functions
</H2>

A function is an extracted procedure into a block of code. We give that block a name so we can call it in different places and as many times as we want, with or without parameters.

We need to understand two things before proceeding. First, JavaScript treats functions as first-class citizens. Functions are values like any other value. You can assign them, pass them to another function, or return them from a function. That is one of the most essential points for the ability to utilize FP principles.

The second principle is the concept of purity. Don't get me wrong, of course, it is hard to think about purity in an unpure world, but for us to benefit from FP concepts we are interested in pure enough

Let's quickly review what a "pure" function is.
First, a function must be idempotent, meaning calling it once or many times will always produce the same output.

It must not interact with the outer world —the global state— nor should it be affected by the outer world, i.e., it should not produce side effects. It must not change the arguments passed in.
<H2>
Side effects
</H2>

A side effect is an event caused by a system within a limited scope in which an effect falls over that scope. So, technically, even if we use console.log inside our functions, the function will be unpure. It's unpure because console.log will fall over the scope of the function it is called on, but we should not be bothered about console.log.

Let's take a look at some impure examples.



```js
const number = 2
const impure = () => 4 + number
```

second one

```js
const impure = fruit => fruit.strain = true
```

And the next one below would be pure enough, Like I already mentioned it's not possible to be completely pure in the unpure world, and we should not be bothered with it in everyday life

```js
const pureRandomNumber = () => 21
```

to explain this statement, "unpure world," let's take an example: make a function that passes all of our requirements to be pure, idempotent, and will not interact with or change anything outside. Heck, it doesn't even have arguments.

```js
const number = pureRandomNumber()
```

require them, and we can affect the outer world and crash the application. However, we don't need to stress about these edge cases and consider these pure functions.

```js
const isNumber = pureRandomNumber((() => { throw 'Bumm'})())
```

When we rely on pure functions, we can achieve cool things. One of them is memoization. Since we are only dependent on inputs to generate outputs if we call the function twice with the same parameters, we can memorize the output, and on the second call, we can return the same result without extra computing.

<H2>
    Loops
</H2>

Loops are imperative. We tell the program exactly how to increment numbers and what to do in each iteration.

```js
for(let i = 1; i <= 10; i++ ) {
    console.log(i)
}
```

If we want to immerse ourselves in the functional paradigm, a functional way to think about loops is through recursion. Recursion is a function that calls itself until specific criteria are met.

Essentially, we run some code and call in function until some criteria are met. In the example above, the criteria would be i = 10;

But recursion is abstract and at first it is really hard to understand how to do it properly but for that, I love the quote from Graham Hutton
<BlockQuote>

Defining recursive functions is like riding a bicycle: it looks easy when someone else is doing it. It may seem impossible when you first try to do it yourself, but it becomes simple and natural with practice.
</BlockQuote>
You just need a lot of practice to make it super easy to write them. When you finally get enough practice, it will be exactly the same as riding a bike, and you will do it without much thinking about it.

So, if we wanted the same result as the example above but more functional, we would do a recursion. I don't advise that every loop problem you solve with recursion.

```js
const logNumbers = (until, from = 0) => {
    console.log(from)

    if(from < until) {
        logNumbers(until, from = from + 1)
    }
}

logNumbers(10)
//or
logNumbers(10, 5)
```

This example is silly, and you would hopefully never write a recursive function for this to loop through a couple of numbers. However, there are some issues that recursion will most elegantly solve while keeping sanity. If you take an example of any tree traversal or manipulation, you will see that at many times' recursion will simplify your code way much and, in some cases, the only way to solve the problem. This means not necessarily improving the performance but improving readability.

Here is an example of a dumb binary search implementation. Again, it is not the best example to show where recursion will shine the most, but we see it is much cleaner than if we do it with loops.

```js
const binarySearch = (
    numbers,
    target,
    low = 0,
    high = numbers.length - 1
) => {
    const guess = Math.floor((high + low) / 2)

    if (target == numbers[guess]) return guess

    return target < numbers[guess] ?
      binarySearch(numbers,  target, low, guess - 1) :
      binarySearch(numbers, target, guess + 1, high )
}
```

One concern with this is the huge memory footprint. Making space on the stack for all function calls would be huge for some problems, but some optimizations, like tail call optimizations, can decrease the memory footprint.

Tail call optimization will allow you to call a function from another function without increasing the call stack. This optimization has been available to JS engines for some time

This is the first part of the series. To be notified when I publish the next part, subscribe to my newsletter.
In the second part, I will continue exploring Lazy Evaluation and more.




<H2>
Introduction
</H2>

Lazy evaluation, a strategy that defers computation until it's absolutely needed, is not just lazy, it's efficient. It avoids unnecessary work until it's necessary to produce a result, making it a powerful concept in programming.
Lazy evaluation, despite its name, is a highly practical strategy. It makes the expression 'lazy' until explicitly called to evaluate a result. Which allows us to work with infinite lists and all forms of perceived infinity. This practicality is one of the key benefits of this technique.
But let's see which mechanisms we can use to defer computation when needed.

In the example, the engine computes the 1 + 1 in the function parameters, and inside the function body, we work with the already computed value.

```js
const incrementNumber = number => number + 1
const value = incrementNumber(1 + 1)
```

Passed arguments in the function 1 + 1 the expression is computed even before we get into the function to compute the number + 2 (arguments passed).

That means that the engine will strictly evaluate expressions instead of lazily. A lazy evaluation would be that we compute 1 + 1 only when needed in the function body, not before invocation.

I know this is a very trivial example, but hopefully, this should show what it would mean to have, by default, strict or lazy evaluation of expressions.


<H2>
    So how can we go around these limitations of strict evaluation inside JavaScript?
</H2>

If we want to postpone evaluations, we must wrap those expressions into the functions since functions cannot be evaluated before calling them.
An example of the incrementing would look something like this:

```js

const incrementNumber = number => number() + 1
const value = incrementNumber(() => 1 + 1)
```

Hopefully, this will give a perspective on how it is possible to delay the evaluation of in-place expressions.

But let's look at an example of how this technique could benefit us in our daily work. For example, we have a list, and we want to transform it into a list with more suitable data to present to users.

Let's use an example that you would certainly use in your day-to-day life. For example, we have a list of eggs ['🥚', '🥚', '🥚'] but we want a list of chickens to present ['🐓', '🐓', '🐓'].


Usually, we would use .map to transform those eggs into the chickens and present them on our page.

```js
['🥚', '🥚', '🥚'].map(() => '🐓')
```
And now we have a list of grown chickens to present.
But let's say we have a huge list of eggs, like thousands or a hundred thousand eggs, to transform into chickens, and we only need a few chickens on the screen to present at a specific moment. Now, mapping through all the eggs would become resource-consuming without actually being necessary.

So, it is an excellent time to get in touch with our toolbox, use the lazy evaluation technique to help us with this issue,
we will rewrite the standard mapping function to a lazy one.

```js
const lazyMap = (arr, fn) =>
 (start, finish) =>
  !finish ?
    fn(arr[start]) :
    arr.slice(start, finish).map(fn)
```
We took an array and mapping function as parameters to our function, which will help us build a lazily evaluated map. We returned a function, which will be our API for accessing our lazy map.

We have two parameters: start and end. If the end is not provided, we get only one item. However, if the end is also provided, we get a full list of items ranging from start to end.

The actual mapping will be done only when we call the function produced by lazyMap. No matter how huge an array we supply to our map function, we will map only those elements that would be affected by start-end parameters.

But can we do even better?

When we execute a mapping function over the values that have already been mapped, we will do the mapping the same as those items that need to be mapped, so it will do double work on those items without any need for that.


I briefly mentioned one optimization technique in my previous blog: memoization. Let's remember what that is. Basically, we compute an expression once and store the result for later if we need that result again. So when we want to map the item again, we reach the already stored computed result instead of executing the mapping again.

First, we will create one function to help us remember the computation.

```js
const memoize = fn => {
  const map = new Map();
  return funarg =>
    map.has(funarg) ?
      map.get(funarg) :
      map.set(funarg, fn(funarg)).get(funarg)
}

```


First, we created a function that takes a function, and we will evaluate and store the result. Then, inside the function, we used key and value storage to store computation associations. We return a function that determines if there is already computed value to pull from the key-value store or to evaluate, store, and return the function result.

We already spoke about pure functions in the previous blog post, which is only possible if our functions are idempotent. No matter how we call the function, we will always compute the same outputs if we use the same inputs. That is why we could store arguments as keys and values as an evaluated function that we would memoize.

Now, we will make some minor changes to our lazyMap function to use the above memoize function.


```js
const lazyMap = (arr, fn) => {
  const memoFn = memoize(fn);
  return (start, finish?) =>
      !finish ?
          memoFn(arr[start]) :
          arr.slice(start,finish).map(memoFn)
}
```

Nothing much has changed, right? We only added a memoize call to our map function, and inside the lazy function, we used a memoized function instead of the original function. Now, just by adding a couple of lines of code, we will see that we would not need to compute the egg's transformation multiple times, but rather just once since pretty much nothing changes. The egg will always produce chicken.

```js
const mapped =  lazyMap(['🥚', '🥚', '🥚','🥚', '🥚'], () => '🐓')

console.log(
  mapped(0,2),
  mapped(1,2)
  mapped(4)
)
```
I'm quite sure now, after all of these chicken and egg examples, you are wondering about a well-known problem: Which one is older? I am glad you got this far. As a bonus, I will write a function to find a solution to that problem, and we will never wonder again.


```js
const chickenEggProblem = () =>
  ['🐓', '🥚'].sort()[0] === '🐓' ?
    'chicken is older' :
    'egg is older'
```

You can inspect the page, copy/paste code into a console, run the code, and see for yourself.

Thanks for taking the time to read it.




Hi, I'm Enso.

Recent
writings.

JavaScript Functional programming demystified - Functions

How to do Lazy evaluation in JavaScript

Hi, I'm Enso.

Recent writings.

JavaScript Functional programming demystified - Functions

How to do Lazy evaluation in JavaScript

Recent
writings.