Discussion on: Why Do You Need to Know About Functional Programming?

products.map(product => {
    product.price = Math.floor(product.price);

    return product;
});

Sorry man but that code is still imperative.

But behind the scenes, map will also return you a brand new array, meaning your original products will be kept intact.

Except that's not true, because you're modifying the elements of the array, which aren't copied.

An actual declarative implementation would be something like this:

products.map( product => ({...product, price: Math.floor(product.price)}) )

criteria

Criteria is the plural, you probably mean the singular criterion (Not criterium, by the way, that's something else entirely)

Function Chaining

Method chaining isn't a functional concept, it's an Object-Oriented one. Some functional languages do have a pipe operator, but most have a function composition operator.

The main problem with Javascript in this case isn't the syntax though, but the fact that it's slower because you're looping over the same data again and again and again. This can be mitigated by smart compilers that do stream fusion to combine them into a single loop, but I'm not aware of whether the big JS implementations actually do that.

Here, Math.random is impure since it always returns a different value, even if we were to pass it the same input. Math.max however is a pure function since it will return the same output given the same input.

You're on the right track there, but you're forgetting the other important part: Math.random also has a side effect, meaning it not only accesses but also modifies external state. If it didn't do this, it would still return the same number every time until something else modified its external state.

Currying is a technique where you call a sequence of functions with one argument instead of calling one function with multiple arguments.

Technically, currying refers to the process of taking one normal function a, b, c, etc. => result and turning it into a curried function a => b => c => etc. => result

It’s important to specify an exit condition otherwise you will create an infinite loop that eventually crashes the browser.

Technically no, as in theory ES6 should optimize tail calls. Sadly none of the big browsers has implemented this so far, which, together with the lack of stream fusion, limits JavaScripts functional capabilities significantly.

In proper ES6, this expression should just run forever const f = e => f(1+e); f(1), but in reality it will still crash at some point and the browser will throw an error.

When we talk about immutable variables and objects, we simply mean that once declared, their value can’t be changed.

Which is not a thing in javascript. You can pretend a variable is immutable, but it's not, which keeps the compiler from making certain optimizations. Say you have an array [1, 2, 3] and want the first few elements. If arrays were truly immutable, JS would not have to copy any data and could just return a new object pointing to the same memory position as the original array but with a different length.

All we can do in JS is pretend, agree to not modify an element and hope everybody else respects this choice, but neither can we be sure of it nor can the compiler.

Thank you for taking the time to read this article, happy coding!

I did a lot of nitpicking, but overall it's a very nice article and I hope it helps a bunch of people discover the nice things FP brings to the programming world :D