loading...

re: Tell us what your top unpopular tech opinion is 😈 VIEW POST

FULL DISCUSSION
 

The promise of functional programming rarely matches reality. Some of the supposed benefits of it are that programs are more concise and easier to understand (or "easier to reason about"), but I have found the opposite to be true.

In the JavaScript world, I feel there is an overuse of the map, filter, and reduce functions and the belief that less code = concise code. This leads to these being used simply for the looping aspect of them. I think that in order for code to be concise, it needs to provide a clear meaning, but it often does not happen when those functions are used.

  • These are not well-named and easy to understand functions due to their dynamic nature. The function names themselves are ambiguous, which is expected since they are built-in utilities.
  • These functions take a function as an argument which applies that operation to the data. Most times the function is declared right alongside the call to map, filter, and reduce. This means that there is no descriptive function to rely on to aid in your understanding, at first glance, you know there is a loop and some action being applied to the items. To understand further, you have to parse every line of code.
  • If these are used all over the code and do not have any descriptive names, it is harder to understand the code.

See the examples below. It is a contrived example, so it isn't that complex and you could argue that pulling out the function is overkill, but I am just showing the difference between the two methods. If the function that is passed into map, filter, and reduce gets more complex, the harder code becomes to parse and understand. The abundance of map, filter, and reduce being used as a "functional" for-loop can harm the readability of code.

let array = [1, 2, 3, 4, 5];

// Function is defined alongside the map, it is used once.
let newArray = array.map( number => number * 4 );

The example below shows that logic being pulled out into a named function. I believe this is easier to read and understand. I think this is more in line with what is referred to as functional programming.

// This function can be tucked away somewhere and allows for it to be re-used.
function multiplyBy(scale) {
    return function(number){
        return number * scale;
    }
}
let array = [1, 2, 3, 4, 5];

// Call map with a descriptive function passed in.
let newArray = array.map( multiplyBy(4) );
 

I think strict functional programming in Javascript doesn't make sense. The lack of built-in currying and parentheses on function calls makes it awkward to write functional code. But, I think applying some ideas from it is useful. The most helpful thing I take from fp in Javascript is keeping functions as pure as possible. I don't mean not using for loops and mutability inside the function, but from the outside, nothing gets changed. Like returning a new array instead of modifying the one passed to it.

 

Yeah, I agree. Writing pure functions and making an explicit choice to introduce a side-effect is a good concept/practice to incorporate into any code. I also like the ideas of immutability and referential transparency, since those are widely applicable.

referential transparency

Well, today I learned. "This set of functional expressions is referentially transparent" seems like yet another way of saying "this bit o' code has got no side effects," but with more syllables!

More syllables is always better.

Referential transparency actually means that the reference of an object doesn't matter. Only the value is important. That basically means that even items in different places in memory that have the same value are considered the same.

Actually, according to Willard Quine[1], "a mode of containment φ is referentially transparent if, whenever an occurrence of a singular term t is purely referential in a term or sentence ψ(t), it is purely referential also in the containing term or sentence φ(ψ(t))," as in the following example:

(12) Ralph believes that the man in the brown hat is a spy.
(13) Ralph does not believe that the man seen at the beach is a spy.
The main in the blue hat = the man seen at the beach = Bernie Sanders
t = ‘the man in the blue hat’
ψ(t) = ‘the man in the blue hat is a spy’
ϕ(ψ(t)) = ‘Ralph believes that the man in the blue hat is a spy’.

I need to get more practice drawing lil tridents on whiteboards.

[1]Although ultimately, like many obtuse concepts in CS, we can safely blame Whitehead and Bertram.

Hmm, well I was talking about referential transparency as it relates to functional programming, as opposed to logic, I guess. I hadn't seen that definition before, it's pretty interesting.

 

When you start to go down the road of transducers, that's when you start to realize it might've been better to have just stuck to a for loop.

And while loops are highly underrated. I've trampolined enough recursive functions to know it's better to just use a while loop and reduce overall complexity-- computational as well as mental overhead.

code of conduct - report abuse